Configuring Atlassian JIRA + Confluence as a support system
I want to share with you my experience in setting up the Atlassian JIRA application registration and processing system, together with Atlassian Confluence as a system of those. user support. What Atlassian writes about this can be found here: http://confluence.atlassian.com/display/JIRA/JIRA+as+a+Support+System
There are several concepts of organizing those. support The first is setting up a separate project for each client. But this concept is not rational due to the fact that those employees. support does not see the overall picture and with a large number of clients there is an oversupply of projects. Therefore, I will tell you about a different concept - with one Service Desk project for all customers with customized scopes.
Let's start by setting up the Permission Scheme for the project, that is, access. You can read how this is done here: http://confluence.atlassian.com/display/JIRA/Managing+Project+Permissions I think it’s pretty obvious that the user should have access to view the project, create requests there, close them, attaching files, leaving comments.
')
Now adjust the scope. In JIRA there is such a thing as Security level. Requests that are at some access level are visible ONLY to those who are allowed to see this access level. Even administrators will not see requests attributed to someone else’s access level. Here, too, there are 2 options, the choice of options depends on your needs. How to create and configure access levels: http://confluence.atlassian.com/display/JIRA/Configuring+Issue+Level+Security
Option 1: we create the Private access level, where we allow those employees. support and Reporter'a tasks. We make this level default. In the Permission Scheme, the Security Level should be disabled by the user (well, or enabled, but then he can leave requests visible to all users, which is also necessary in some situations). So, any simple user will see only their requests, and those of those. support - all requests that we need.
Option 2: this option provides for multiple levels of security for groups of clients, this is required if our clients are companies with many employees, and requests should be common to all employees of one company. Accordingly, first we need to create the appropriate access levels for each client. Then we need the We engineer plugin ( https://plugins.atlassian.com/plugin/details/22874 ). It allows you to set the Security Level depending on the Project Role as a post-function Workflow (application life cycle, you can read about it and its settings here: http://confluence.atlassian.com/display/JIRA/Configuring+Workflow ). We create additional Project Roles corresponding to the client (Users, Groups & Roles -> Project Role Browser), in the Service desk project we assign this role to the corresponding group of users. Then we go to the settings of our Workflow, go to the first Transition - Create and add a post function, as indicated in the documentation for the plugin. ( Important note: when we create these functions in the first step (creation), we must put them first. In the other steps, the last ones. ) Thus, when creating an application, the security level will be set to automatic.
I will not talk about setting up Workflow, because everything you need to know is described here: http://confluence.atlassian.com/display/JIRA/Configuring+Workflow
Still it is necessary to tell about a method of transfer of applications to developers. For this, it is convenient to use the Clone Plus plugin ( https://plugins.atlassian.com/plugin/details/44043 ). Just put it and the Clone ++ button appears, which allows you to clone the request with all comments and attachments to another project. The clone and the original will be linked by reference.
In general, there are quite a few plug-ins that help use JIRA as a support system. They can be found here: https://plugins.atlassian.com/search/category/21338 .
Now about Confluence.
The main functions can be found here: http://confluence.atlassian.com/display/DOC/Confluence+Documentation+Home
Besides the fact that in this system you can store documentation with different levels of access, there is another useful feature: if you configure Confluence to synchronize with the JIRA system, you can give some users “administrator rights” in their group so that it can add users into their groups and remove them from it. That is, the company itself can manage its employees and their access in the system. In this case, you can open the registration, but prohibit the newly registered users to do something until they have been registered by the admins. To do this, you need the Custom Space User Management Plugin ( https://plugins.atlassian.com/plugin/details/133?versionId=373044 ). We create a sandbox for each client, in which it will be a complete owner, create groups with a prefix, which is the key, these are sandboxes, and give these groups appropriate access to JIRA and Confluence.
That's all for now, if someone has an interest, I can go deep into some moments.
There are several concepts of organizing those. support The first is setting up a separate project for each client. But this concept is not rational due to the fact that those employees. support does not see the overall picture and with a large number of clients there is an oversupply of projects. Therefore, I will tell you about a different concept - with one Service Desk project for all customers with customized scopes.
Let's start by setting up the Permission Scheme for the project, that is, access. You can read how this is done here: http://confluence.atlassian.com/display/JIRA/Managing+Project+Permissions I think it’s pretty obvious that the user should have access to view the project, create requests there, close them, attaching files, leaving comments.
')
Now adjust the scope. In JIRA there is such a thing as Security level. Requests that are at some access level are visible ONLY to those who are allowed to see this access level. Even administrators will not see requests attributed to someone else’s access level. Here, too, there are 2 options, the choice of options depends on your needs. How to create and configure access levels: http://confluence.atlassian.com/display/JIRA/Configuring+Issue+Level+Security
Option 1: we create the Private access level, where we allow those employees. support and Reporter'a tasks. We make this level default. In the Permission Scheme, the Security Level should be disabled by the user (well, or enabled, but then he can leave requests visible to all users, which is also necessary in some situations). So, any simple user will see only their requests, and those of those. support - all requests that we need.
Option 2: this option provides for multiple levels of security for groups of clients, this is required if our clients are companies with many employees, and requests should be common to all employees of one company. Accordingly, first we need to create the appropriate access levels for each client. Then we need the We engineer plugin ( https://plugins.atlassian.com/plugin/details/22874 ). It allows you to set the Security Level depending on the Project Role as a post-function Workflow (application life cycle, you can read about it and its settings here: http://confluence.atlassian.com/display/JIRA/Configuring+Workflow ). We create additional Project Roles corresponding to the client (Users, Groups & Roles -> Project Role Browser), in the Service desk project we assign this role to the corresponding group of users. Then we go to the settings of our Workflow, go to the first Transition - Create and add a post function, as indicated in the documentation for the plugin. ( Important note: when we create these functions in the first step (creation), we must put them first. In the other steps, the last ones. ) Thus, when creating an application, the security level will be set to automatic.
I will not talk about setting up Workflow, because everything you need to know is described here: http://confluence.atlassian.com/display/JIRA/Configuring+Workflow
Still it is necessary to tell about a method of transfer of applications to developers. For this, it is convenient to use the Clone Plus plugin ( https://plugins.atlassian.com/plugin/details/44043 ). Just put it and the Clone ++ button appears, which allows you to clone the request with all comments and attachments to another project. The clone and the original will be linked by reference.
In general, there are quite a few plug-ins that help use JIRA as a support system. They can be found here: https://plugins.atlassian.com/search/category/21338 .
Now about Confluence.
The main functions can be found here: http://confluence.atlassian.com/display/DOC/Confluence+Documentation+Home
Besides the fact that in this system you can store documentation with different levels of access, there is another useful feature: if you configure Confluence to synchronize with the JIRA system, you can give some users “administrator rights” in their group so that it can add users into their groups and remove them from it. That is, the company itself can manage its employees and their access in the system. In this case, you can open the registration, but prohibit the newly registered users to do something until they have been registered by the admins. To do this, you need the Custom Space User Management Plugin ( https://plugins.atlassian.com/plugin/details/133?versionId=373044 ). We create a sandbox for each client, in which it will be a complete owner, create groups with a prefix, which is the key, these are sandboxes, and give these groups appropriate access to JIRA and Confluence.
That's all for now, if someone has an interest, I can go deep into some moments.
Source: https://habr.com/ru/post/125622/
All Articles