Sergei Gridnevskii Rising Star

Yes thanks. Just received a cap from Atlassian, looks nice.

Finally I found an answer. The post should be like this: "customfield_14472": [{"workspaceId":"e02eca9b-beba-4406-bcbc-6c95dcb24212","id":"e02eca9b-beba-4406-bcbc-6c95dcb24212:8155","objectId":"8155"}] How to get workspace ID? Set the field in the issue manually and then go to…

Strange, When I set an Insight field from another field it works fine. Key="{{customField_14472}}" When I set it using text I get Internal Server Error. Name LIKE "{{approle.Role.Name}}" My head is going to blow up.

I may be mistaken but we always had such a possibility - I added links to KB in fields descriptions long ago. Like this: Fix issue with customer data ^_[help|https://oursite.atlassian.net/servicedesk/customer/kb/view/540410186?applicationId=20616891-9798-3e01-8526-a8f25b3f683d&title=Data+Fixes+Form]_^ This is how it looks…

Is it possible to select approver by email, not by name? We have people with same name in Jira.

For me it is pretty easy. I meet with the stakeholder, choose Projects in top level menu and ask him to select one of atlassian templates. We create the temporary projects together, I assign stakeholder as admin to this project and he plays with it for a week or so. Then he comes to me saying Lets do it like this but…

OK we found the reason for that. The smart value contained space before first { Now it works fine. Strange that Atlassian do not do trim before applying logic to smart value fields. Even stranger that logic works differently if there is one value or a couple.

I guess you need to add that roles help to standardize projects permissions. One can have a single permission scheme that suits any project. And then assign users to roles on this project. E.g. you have one project for Middleware and another for Frontend. Developers role can be assignable, work on issues, browse and so on…

I think using groups in permission schemes is a bad idea. Moreover I recommend removing all groups and individual users from permission schemes. Roles is what should be used. 1. Make a role Issue Creators. 2. Remove any users and groups from Create Issue permission in permission scheme 3. Add Issue Creators to this…

We have test cases in Jira that are prepared in Confluence by analytics and then copied to Excel/CSV and imported to Jira. The process is pretty straightforward - just look at @Joseph Chung Yin comment. I will add some tips. 1. Jira will create new custom fields for most columns in your CSV (if it does not find anything…

You see it becomes more and more complex and I hate rules that do not fit on one screen. Splitting rule to several rules makes it much more easier to support. And I think atlassian loves it because it has to run a rule on one server while it can run 10 rules on 10 different servers in cloud and finish the whole task 10…

What if he is in a big organization and someone creates another issue at exactly same time?

Well the easiest way - by comparing the Summary of the ticket with a predefined string. This of course make it possible that someone uses this string and triggers your rule - but you may be creative, e.g. by using something like [Autotask785] Check server logs and then search for [Autotask785] in Summary If you do not like…

If you use Automation for Jira - you need second rule that will trigger on issue creation. Check summary and create subtasks.

I applied for vacancy in ALM Works 5 years ago, unfortunately did not pass the second interview

We used to have JMWE for years but Automation for Jira naturally killed it. Now we use it only for complex conditions on issue creation.

For SOC2 it would be very useful to backup Jira logs every month. They are deleted by Jira after some time and it really frustrates me. Why? They are not that big in terms of storage, just a text file that can be zipped with great compression ratio. I would appreciate if Atlassian creates auto backup and possibility to…

Amir good point. I create new automation rules almost every day and some of them are too complex to test them on real users. So I can have 5-6 test tickets that my users are not happy to see in their reports. But I clearly identify them as "This is a test issue" in summary and delete as long as I do not need them.

Good that you started to think of audit. Maybe Atlassian will create code that can print an issue with all comments and history? I have real trouble with this - of course I can use REST API to extract full issue details, convert it to HTML and print, but they will never believe that it is an original issue unless I apply…

Well you can use Issue based security to limit those who can see these issues. But this will require discipline from your side. I think best option would be to use external password storage. And put the link to the storage in comment. When anyone clicks on it he will authenticate himself and will get a password. Something…

This works {{webResponse.body.employees."603"}} It returns {id=603, action=Inserted, lastChanged=2022-05-03T15:16:30+00:00} However I do not know "603" for every response, today it is 603, tomorrow it will be 620. It would be nice to have something like a list of keys of a json object {{webResponse.body.employees.keys}}…

We have many Jira Software projects. Is it possible to use forms there? I would like to see them in Bugs.

Unfortunately this does not work anymore since atlassian changed GUI and removed portal users editing possibility.

BTW audit log has REST API and I plan to have a scheduled job that will extract logs once in 3 months and store it in appropriate location. Jira cloud deletes logs after some time and it is a good idea to backup them for inquiries.

Standardization gives less flexibility. And users hate us more.

I oppose sharing schemas. Because when one team makes changes immediately another team member jumps in and runs to me and asks to remove changes. It is easier for me as admin to have a scheme per project. Maybe if you have only one team it will work. Me having 10+ teams am too lazy to negotiate changes with everyone. I…

Yep, but you may hide global priority in default field configuration and use custom field with same name with many contexts.

That's why they have contexts in Jira. Every field with a name and a type can have any number of contexts where you put various initial values, options (in case of lists) and even insight queries. I recommend using contexts as long as they eliminate many problems.

1. I use context for every new custom field where I select only projects and issue types that require this field 2. I have a default fields config where all fields are hidden. When I add a new custom field I go to this default config and hide the new field. Whenever I create a new project I make a copy of default config…

You can subscribe to Jira Cloud and play around with it for free for 1 month. Then you can renew subscription. Practice makes perfect. There are plenty of project templates there. Create a project from template, check it out how they make workflows and other stuff and fit to your organization. Templates are pretty good to…