Online Help

AVS User Guide is a 81 pages PDF document containing all the details about how AVS should be used and explanations about the features available within each client view (workspace, change requests, project, administration).

This documentation can be downloaded for free here.

Getting started..

Start the server - Windows, User mode
From Windows "start" menu, the server is being launched for the very first time!

If a version 3.x was installed on the same host, starting AVS 4.x will perform a data migration. In this case, the root user will have been defined by the dedicated dialog when starting AVS 3.x for the first time. Otherwise the root user login = "root", password = "root".

Start the server - Windows, Service mode

Tomcat web server installs a Win32 service called "Apache Tomcat". By default, the service startup is configured as "automatic", and launched from the System account, without the need of having an active windows session opened.

Start the client

At that stage, the database is created and only the root user can log onto the system. To do so, he must open a browser on http://tomcat-server:8090/avs/jnlp?page=welcome dynamic page, where 'tomcat-server' is either the avs server hostname or its ip address.

This web page contains a link to start AVS client application, which will be launched through JNLP. This requires a Java Runtime Environment >= 1.5 installed on your client host.

User management

From the user management view, the administrator can create groups and users. Default groups:

  • Administrator
  • Super Users
  • Tester
  • Integrator
  • Developer
  • Project Leader

You can create as many group as you want. For each group, you can select the access associated within the following list:

  • Administer server: create users and groups, change server parameters
  • Create CR: can create a new change request or bug
  • Change CR severity: can modify change requests' severity
  • Change CR state: can change a change request state
  • Close CR: can close a change request
  • Auto assign CR: can assign a change request to self
  • Assign CR: can assign a change request to anyone
  • Query CR: fetch change requests matching a set of given parameters
  • Manage projects: create projects, target releases and update templates
  • Manage files: can create, delete and modify files and folders

New access controls created from the change request life cycle editor will also appear here.

Project management

From the project management view, the project manager can create empty projects and the corresponding target releases. If the project manager owns the "manage file" access control, he will be able to use the project wizard to create a very first import.

He can also define "update templates", which can either be dynamic or static. First type will be used by developers to update their workspace, second one for build management.

The project manager can also define here which users will be affected to each project, select the appropriate change request life cycle for his projects, define a text configuration for change requests, and scripts launched on either task close event, change request reaching a final state, or periodically.

Change requests

The change request view allows creating change request, which type can be either "bug" or "enhancement". The user can query change requests upon following criterias:

  • severity
  • current state
  • assigned user
  • linked project
  • issue date

Users can store their change request queries for later reuse. Query result can be exported in CSV format, and each change request history can be viewed. It will show all the states a change request has gone throught, create development task, additional comments, attachments, etc..

Life cycles

Adminstrator are responsible for creating change request life cycles. These allow adapting AVS to the process users are used to within their company.

New states and transitions can be created. New transitions can be restricted to new custom access rights. In such case, only users owning these access rights will be allowed to use these transitions to update change requests' states.

Project managers can then select the most appropriate change request life cycle for their project.

Client workspace

Developers can open a workpsace for each projects defined by the project manager, provided they have been affected to these projects. For a given project, they can open as many workspace as open target release defined by the project manager.

They will need to select an "update configuration" to update their workspace.

They can add file, folders, perform file merge when using a parallel version for a given file, compare with a previous version, etc...

Moving a file or a folder is very efficient and does not loose the corresponding history.

Every change on the workspace will require a development task. These are created by developers on the change requests they have been assigned by either the project manager, the tester or even themself if they own the "auto assign CR" access right.