Configuration Scenarios#
This section contains examples of configuration scenarios related to roles and permissions, item types, and workflows.
A common scenario is to grant customers access to the system, but in a way that they only see their own entries. Developers should be able to see all entries, including internally created tasks. There are three ways to achieve this setup in Allegra.
Customers are assigned the “External” role. This way, they can only see their own items. A downside is that entries from these customers are not grouped. If there are multiple people associated with this customer, each can only see their own entries, but not those of their colleagues from the same company. If each customer is given a collective account, this is usually not an issue.
If there are only a limited number of customers, a list is created for each customer. Only persons associated with this customer and developers are given access to this list. Customers can now have extended rights to this list, and all persons associated with this customer can see all tasks in this list.
A separate project is created for each customer. Internal developers can access all projects, while customers can only access their specific project. This allows the use of finer classification of different lists even with many different customers.
Each solution has its unique advantages, and it depends on the number of customers and how you connect the system with the customer, which solution is preferable.
To allow anonymous access to the system, create an “anonymous” account or use the predefined “Guest” account without a password or with a public password and grant this user all desired access rights. Public passwords can be published on the login page, for example.
It is possible to configure Allegra so that you have your personal To Do list, which is not visible to others. There are three ways to achieve this. One solution is to define a new project, e.g., called “Personal,” and assign each user the “External” role. This allows you to create, modify, and close items that only you can see.
The second approach is to define a new item type “personal items” and, through access restriction on the access permissions page, specify that only the “External” role can access this list.
The third approach is to use the privacy flag on items you want to hide. You can set this flag when creating objects or later when you modify your own item. It is not possible to set the privacy flag on items that you did not create.
Here is an example of a lean configuration. This works very well for small teams, in open cultures with less formal approaches.
The following item types are used:
Tasks
Milestones
You can delete all other item types.
You can use the default priorities and severities.
The following states are used:
Open
Suspended
Completed
In Progress
No workflows should be configured. This way, it is possible to transition from any state to another state. All team members have a “responsible” role. This will give you a solid, but open process that is very efficient for small teams.
Here is an example of a lean but more formal configuration. This works very well for larger teams, where it may be necessary to restrict state changes to certain persons, e.g., only a tester can close an item or marketing should not see bugs known only to developers.
The following item types are used:
Tasks
Problem Reports
Request for Enhancement
Milestones
You can delete all other item types.
You can use the default priorities and severities.
The following states are used:
Open
Analyzed
Assigned
Suspended
Testing
Completed
In Progress
Item type access should be restricted to specific roles; for example, marketing may only be able to see milestones and requests for enhancements, while developers should be able to see everything.
Reasonably open workflows should be configured. In general, any state transition is possible with few exceptions. You should not ask yourself, “who should be able to perform this transition,” but “is there any reason why no one should be able to perform this transition?” This will lead to a more practical workflow than if you only consider the “good” case without considering the many exceptions that may occur during a project.