Atlassian JIRA Service Desk: brief information and some tricks for usability (using sil-scripts and sql)
Hello!
I want to tell you briefly about the product from Atlassian: JIRA Service Desk
More precisely, about some tricks that greatly improve the usability of the product, because About the plugin itself now many in the know.
By name it seems so clear why this plugin is for JIRA to implement the functionality of the Service Desk. But, in my opinion, the most important thing is accepting applications from users in a more convenient and beautiful design, using a separate portal for a specific project. And it does not matter if you want to organize the service desk service or simply receive applications for a project.
')
If to be expressed more precisely and more widely, then the plugin adds the following functionality to JIRA:
You can use this functionality as you wish: fully, to implement the reception and processing of requests by the Service Desk, for example, only setting SLA levels to monitor the timeliness of the execution of requests filed using conventional methods, or you will use queues of requests, or just the convenience of the portal receiving applications
So, now about the tricks (about the use and configuration of the plugin itself, I began to write an article, but I did not finish it, because there are a lot of things: if someone needs much, I can write, but for now without it)
So, we set up a form on the portal for submitting a certain type of applications. The portal gives us an excellent opportunity not only to specify the order of the fields, but also to give them other names for the screen for submitting a specific type of application - for a better understanding of the user, and also to add a comment.
This is all well and good, of course: for the “Size” field I will write “Specify the size of the disk” for one type of applications, and for the other “Screen size”, I will have one field, but no one will get confused when submitting an application what should be there ( This is a simple example to understand.
But the problem is that in the end there are not only a dozen or even hundreds of such very unique fields for very different information. And even if some fields are used for different types of application, but for similar information, the number of real fields in JIRA will not decrease much. Now imagine a poor administrator who has to start this bunch of fields - and do it all the time, because projects grow, add, etc. Can't imagine? I, too, better not.
But there is a solution!
It is, of course, with restrictions: if you need some fields (preferably most of these are specific) you need only further information and you don’t need to edit them separately (well, they submitted an application, where 15 fields describe some parameters, you read them, understand and did the work, nothing else), then we have fun solving this problem. The administrator must give us the rest of his life, he will only have to study the jjupin plugin and a little sql, and together with you persuade the management to buy this plugin.
Decision
Subtleties and problems
For string, text and other fields, in which there is no pre-filled information, there are no problems at all
But for different lists we have problems: the filled value of the field can be different only in the context of projects (field configuration), inside the project the value for all types of applications will be the same. In this case, if several such unique fields are used in one project in different applications, then they will have to be made just such an amount: UniversalFieldListBox01, UniversalFieldListBox02, etc. It saves the fact that in other projects they can be used without problems with their values.
Script
So, create a sil-script specified below and call it when creating an application (this code can be placed in a separate module as a function and use its call from other scripts in order not to write for each project)
We have JIRA running on MS SQL Server, sql in the script for it, if you have another database, you may have to change the syntax a bit:
Hooray, everything works!
The result looks like this (this is the “Description” field in the application):
Honestly, this decision simply saved us from a disaster (well, more precisely, administrators).
No, not quite everything works: now we don’t want everyone, anyone, to make applications directly through JIRA - they need to be sent to the portal, everything is beautiful, white and fluffy. But how to do that? Write, do not write - there will definitely be someone who will make an application through JIRA and fill everything in a wrong way (more precisely, it will not fill anything at all, because there is only UniversalField, etc.)
On the other hand, one's loved ones should be allowed to make applications directly, because ... well, you understand.
Decision
We solve all the same sil-script, all the same when creating the application, but already use it as a validator
Additionally, you need to create a role (or use an existing one) in the project, in which there will be those people who have the right to create applications from JIRA:
Let's imagine that you need to have a couple dozen screens on the portal, and all of them are mostly with the same fields.
Yes, even take one or two new screens
Those. it is ... add eleven times 10 fields each, give them all the names, comments, set the order and obligation
It is of course, you can manually fill them from beginning to end - and we did it.
But there is a way that speeds up this process enough: run a sql query that will do all the rough work
So, we first create the necessary number of screens - with our names, groups, etc., but we don’t go to the fields
Then we take one screen and set up on it all the fields that we will have in all the screens.
Next, we will need the ID of this screen template and the ID of all the other screens that we have created. ID can be seen in the browser address bar when editing the fields of a particular screen.
In turn, we substitute these IDs into the script and run. It is possible to pull out all the IDs of the screens through the same sql query and execute the script one by one, you can even finish the sql query so that it does everything there — this is not important anymore. An example of how easy and simple it is to operate with the settings of the screens and the portal service portal is important: for each screen we add to the field table those fields that are in the screen template and not in this screen and in the order they are located there.
Press F5 after launching the query - and you will see all these fields right now on the screen.
Next you will tune up the little things
Script
The syntax of MS SQL, also do not forget that the name of the tables of the plugin, you can not begin with "AO_54307E_", so you need to change it in the query
Generally speaking, through sql queries (of course knowing sql), you can do a lot of things in the service desk, but in general, and in the whole JIRA (although it is advisable not to edit the JIRA data, but only to watch, you never know, but the service desk is open for any actions )
For example, it is possible to change the name / obligatoriness / comment / number in order, on an orderly basis on all the necessary screens of a specific field, or change the order of all the fields according to some example screen, etc.
Well, now the beauty!
Well, not quite true - no pictures.
Maybe I forgot something - then I will add.
Questions welcome advice too.
I want to tell you briefly about the product from Atlassian: JIRA Service Desk
More precisely, about some tricks that greatly improve the usability of the product, because About the plugin itself now many in the know.
For tricks, you need to use scripts in postfunctions, in this case they are sil-scripts of the JJupin plugin, and be able to write and execute (including from the script) sql queries to the database, where JIRA stores its data. On the use of the plugin briefly in another article: "Atlassian JIRA: setting up the processing of applications using the plugin JJUPIN . "
JIRA Service Desk
By name it seems so clear why this plugin is for JIRA to implement the functionality of the Service Desk. But, in my opinion, the most important thing is accepting applications from users in a more convenient and beautiful design, using a separate portal for a specific project. And it does not matter if you want to organize the service desk service or simply receive applications for a project.
')
If to be expressed more precisely and more widely, then the plugin adds the following functionality to JIRA:
- the user portal itself, where users can create applications, see a list of already submitted applications with brief information on them and statuses;
- customization of the user portal;
- the ability to set SLA values ​​for applications with indication of conditions via jql request;
- reporting on the specified SLA;
- queue of requests with an indication of the conditions of selection through jql-request;
- opportunity to fasten the Knowledge Base to the portal.
You can use this functionality as you wish: fully, to implement the reception and processing of requests by the Service Desk, for example, only setting SLA levels to monitor the timeliness of the execution of requests filed using conventional methods, or you will use queues of requests, or just the convenience of the portal receiving applications
Regarding licenses for JSD there are subtleties: now they are required only for those users who will process applications in projects in which the Service Desk is turned on (they are called agents), without restrictions on the number of applicants. It used to be the number of licenses in JIRA and those and those.
On the one hand, if you have only 2-3 people process applications submitted through the portal, then it is economical. But if your applications are processed by many users - well, for example, in the mode when all projects are connected to JSD, applications are accepted through the portal, and users of these projects / departments process them, respectively, there is already sadness: the price for the number of agents from 15 and up quickly go into space. We managed to buy under the old scheme, so there are no problems.
In my opinion, this plugin lacks another mode of operation and licensing: using it only as a portal for receiving applications, with the number of licenses equal to that in JIRA, and, accordingly, a more humane price. Because most of our projects use nothing but a portal (well, in some places sla, at least) are used. Of course, it can be a separate plugin with a portal, but this is another portal that is not good. Maybe someone will write? I would have written it myself, but I don’t know how to do this
So, now about the tricks (about the use and configuration of the plugin itself, I began to write an article, but I did not finish it, because there are a lot of things: if someone needs much, I can write, but for now without it)
Variety of information fields
So, we set up a form on the portal for submitting a certain type of applications. The portal gives us an excellent opportunity not only to specify the order of the fields, but also to give them other names for the screen for submitting a specific type of application - for a better understanding of the user, and also to add a comment.
This is all well and good, of course: for the “Size” field I will write “Specify the size of the disk” for one type of applications, and for the other “Screen size”, I will have one field, but no one will get confused when submitting an application what should be there ( This is a simple example to understand.
But the problem is that in the end there are not only a dozen or even hundreds of such very unique fields for very different information. And even if some fields are used for different types of application, but for similar information, the number of real fields in JIRA will not decrease much. Now imagine a poor administrator who has to start this bunch of fields - and do it all the time, because projects grow, add, etc. Can't imagine? I, too, better not.
But there is a solution!
It is, of course, with restrictions: if you need some fields (preferably most of these are specific) you need only further information and you don’t need to edit them separately (well, they submitted an application, where 15 fields describe some parameters, you read them, understand and did the work, nothing else), then we have fun solving this problem. The administrator must give us the rest of his life, he will only have to study the jjupin plugin and a little sql, and together with you persuade the management to buy this plugin.
Decision
- We understand what the maximum number and what type of unique fields can be simultaneously on the application creation screen (if we add something later). There will be a dozen, well, a little more - compare with the list of all unique fields;
- We add these fields to JIRA in the form of type UniversalFieldString01, UniversalFieldString02, UniversalFieldMemo01, etc. (you can give your names, the main thing is to take this into account in the script);
- We add all these fields to the screen for creating applications in those projects where they will be used (in addition to standard topics, descriptions, etc., so that we will have them when creating an application);
- When setting up an application screen on the portal, we add these fields in the required quantity for this type of application (as many strings, as many text, etc.);
- We indicate to these fields the names and comments that this type of application should have;
- We write a script that we call when creating an application, and which of these fields and their entered values ​​makes up a single text in the form of "field name: field value" on each line (well, or whatever) and adds this text to the description of the application;
- We rest.
Subtleties and problems
For string, text and other fields, in which there is no pre-filled information, there are no problems at all
But for different lists we have problems: the filled value of the field can be different only in the context of projects (field configuration), inside the project the value for all types of applications will be the same. In this case, if several such unique fields are used in one project in different applications, then they will have to be made just such an amount: UniversalFieldListBox01, UniversalFieldListBox02, etc. It saves the fact that in other projects they can be used without problems with their values.
Script
So, create a sil-script specified below and call it when creating an application (this code can be placed in a separate module as a function and use its call from other scripts in order not to write for each project)
We have JIRA running on MS SQL Server, sql in the script for it, if you have another database, you may have to change the syntax a bit:
string[] flist; string _portalid = 1; //ID Service Desk, ".._VIEWPORT", string sqlq; integer qty; integer i; string s; string sf; string sv; // !!! , "VIEWPORT" sql- "AO_54307E_" , // , ID : "UniversalField..." sqlq = " select PFF.Field_ID, PFF.Label, F.CFName "; sqlq = sqlq + " FROM [Jira].[dbo].[AO_54307E_VIEWPORT] P "; sqlq = sqlq + " join [Jira].[dbo].[AO_54307E_VIEWPORTFORM] PF on PF.ViewPort_ID = P.ID "; sqlq = sqlq + " join [Jira].[dbo].[AO_54307E_VIEWPORTFIELD] PFF on PFF.Form_ID = PF.ID and field_ID like '%custo%' "; sqlq = sqlq + " join [Jira].[dbo].[customfield] f on 'customfield_' + cast(f.ID as varchar) = PFF.Field_ID and F.CFName like 'UniversalField%' "; // (UniversalField....) sqlq = sqlq + " where P.ID = " + _portalid; sqlq = sqlq + " and PF.[Key] = replace('" + customfield_12700 + "', '" + project + "/', '') "; // customfield_12700 "customfield_" ID "Customer Request Type" ( customfield), JIRA , , flist = sql("jiraDS", sqlq); // jiraDS - (datasource) JIRA, jjupin qty = arraySize(flist); i = 0; s = ""; while (qty > i){ sv = getElement(flist,i); // sf = %sv%; // if ((indexOf(getElement(flist,i+2), "UniversalFieldDate") >= 0)) // - , ( "Universal..." ) { sf = formatDate(%sv%, "dd.MM.yyyy"); } if (sf != "") // , " " + + " " + 2 ( ) { s = s + getElement(flist,i+1) + ": \n" + sf + "\n\n"; } i = i + 3; }; if (s != "") // - , , , , { if (desc != "") { s = s + "========= \n\n"; } desc = s + desc; } Hooray, everything works!
The result looks like this (this is the “Description” field in the application):
The name of the program:
Kaspersky Anti-Virus
Utility need:
really needed
Computer Name:
komp13
=========
Good day!
Colleagues, please install an antivirus on your computer
Honestly, this decision simply saved us from a disaster (well, more precisely, administrators).
All on the portal!
No, not quite everything works: now we don’t want everyone, anyone, to make applications directly through JIRA - they need to be sent to the portal, everything is beautiful, white and fluffy. But how to do that? Write, do not write - there will definitely be someone who will make an application through JIRA and fill everything in a wrong way (more precisely, it will not fill anything at all, because there is only UniversalField, etc.)
On the other hand, one's loved ones should be allowed to make applications directly, because ... well, you understand.
Decision
We solve all the same sil-script, all the same when creating the application, but already use it as a validator
Additionally, you need to create a role (or use an existing one) in the project, in which there will be those people who have the right to create applications from JIRA:
if (customfield_12700 != "") // customfield_12700 "customfield_" ID "Customer Request Type" ( customfield), JIRA , , : , { return true; } // JIRA, , , - if (isUserInRole(currentUser(),project, " ")) { return true; } // , , string s; s = " Service Desk! , : http://.... ( )"; return false, "", s;
Some little things
Let's imagine that you need to have a couple dozen screens on the portal, and all of them are mostly with the same fields.
Yes, even take one or two new screens
Those. it is ... add eleven times 10 fields each, give them all the names, comments, set the order and obligation
It is of course, you can manually fill them from beginning to end - and we did it.
But there is a way that speeds up this process enough: run a sql query that will do all the rough work
So, we first create the necessary number of screens - with our names, groups, etc., but we don’t go to the fields
Then we take one screen and set up on it all the fields that we will have in all the screens.
Next, we will need the ID of this screen template and the ID of all the other screens that we have created. ID can be seen in the browser address bar when editing the fields of a particular screen.
In turn, we substitute these IDs into the script and run. It is possible to pull out all the IDs of the screens through the same sql query and execute the script one by one, you can even finish the sql query so that it does everything there — this is not important anymore. An example of how easy and simple it is to operate with the settings of the screens and the portal service portal is important: for each screen we add to the field table those fields that are in the screen template and not in this screen and in the order they are located there.
Press F5 after launching the query - and you will see all these fields right now on the screen.
Next you will tune up the little things
Script
The syntax of MS SQL, also do not forget that the name of the tables of the plugin, you can not begin with "AO_54307E_", so you need to change it in the query
declare @form_id int, @newform_id int set @form_id = -- ID - set @newform_id = -- ID , INSERT INTO [Jira].[dbo].[AO_54307E_VIEWPORTFIELD] ([DESCRIPTION] ,[DISPLAYED] ,[FIELD_ID] ,[FIELD_TYPE] ,[FORM_ID] ,[LABEL] ,[REQUIRED] ,[FIELD_ORDER]) select [DESCRIPTION] ,[DISPLAYED] ,[FIELD_ID] ,[FIELD_TYPE] ,@newform_id ,[LABEL] ,[REQUIRED] ,[FIELD_ORDER] from AO_54307E_VIEWPORTFIELD f where FORM_ID = @form_id and not exists(select 1 from AO_54307E_VIEWPORTFIELD f2 where f2.FORM_ID = @newform_id and f2.FIELD_ID = f.FIELD_ID)
Generally speaking, through sql queries (of course knowing sql), you can do a lot of things in the service desk, but in general, and in the whole JIRA (although it is advisable not to edit the JIRA data, but only to watch, you never know, but the service desk is open for any actions )
For example, it is possible to change the name / obligatoriness / comment / number in order, on an orderly basis on all the necessary screens of a specific field, or change the order of all the fields according to some example screen, etc.
Well, now the beauty!
Well, not quite true - no pictures.
Maybe I forgot something - then I will add.
Questions welcome advice too.
Source: https://habr.com/ru/post/265385/
All Articles