Configuration Scenarios¶
This section contains examples of configuration scenarios that relate to roles and permissions, item types, and workflows.
A common scenario is to grant customers access to the system, but in such 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 to the “External” role. This way, they can only see their own items. A disadvantage can be that entries from these customers are not grouped. If there are several 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 group account, this is usually not a problem.
If there are only a limited number of customers, a list is created for each customer. Only people associated with that customer and developers will have access to this list. Customers can have extended rights to this list, and all people associated with this customer can see all the 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 for a finer classification of the different lists to be used even with many different customers.
Each situation has its unique advantages and depends on the number of customers and which solution is preferable.
To provide anonymous access to the system, create an “anonymous” account or use the predefined “guest” account without password or a public password and grant this user all the desired access rights. Public passwords can be published, for example, on the login page.
It is possible to configure Allegra so that your personal To Do list is not visible to others. There are three ways to achieve this. One solution is to define a new project called “Personal”, for example, and assign the role “External” to each user. This allows you to create, modify, and close items that only you can see.
The second approach is to define a new item type called “Personal Items” and assign the role “External” to each user via access restrictions on the “Access Permission” page so that they can easily access this list.
The third approach is to use the privacy flag on items you want to hide. You can set this flag when you create items, or later on when you modify your own items. 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:
Opened
Suspended
Closed
Processing
No workflows should be configured. So it is possible to go 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 streamlined but more formal configuration. This works very well for larger teams, where it may be necessary to restrict government changes to specific people, so that, for example, only a tester can close an item, or that marketing should not see bugs that are only known.
The following item types are used:
Tasks
Problem reports
Call for enlargement
Milestones
You can delete all other item types. Also, you can use the default priorities and severities.
The following states are used:
Opened
Analyzed
Assigned
Suspended
Test
Completed
Processing
Item type access should be limited to the specific roles you assign. For example, while the marketing department may only be able to see milestones and requests for improvements, developers should be able to see everything.
Reasonably open workflows should be configured. In general, any state of transition is possible with a few exceptions. You should ask yourself not “who should be able to perform this transition?” but “is there any reason no one could perform this transition?”. This will lead to a more practical workflow than if you just go ahead and consider the “good” case without keeping in mind the many exceptions that might occur during the course of a project.