Hello Community,
We have installed the Checklist for JIRA by Okapya Software in our Data Center based Jira instance.
We are running Jira Software DC 9.16.x and the Checklist for JIRA by Okapya Software App is version 7.1.1
I have a question regarding the deletion of checklist elements.
We would like to have it so that users can only delete elements they create.
We also use the Checklist Templates feature a lot, when creating issues.
These checklists from a template then seem to behave like Local items, which means that anyone can delete them, or elements they contain.
In the Addon Checklist permissions scheme that is used for the project, under All Permissions > Edit Checklist > Delete Elements, we have no rule set.
Under All Permissions > We have the Project roll Administratoes set.
If we do set a rule in the 'Delete Elements' section, then users can delete elements from the Template checklists, as well as elements they create them selves.
Is there anyway to protect Checklist elements that were created, or belong to a Template, from being deleted?
I have not found anything in the Permissions Scheme,the Template settings, or the fields configuration scheme.
Working with templates (okapya.com)
Working with permission schemes (okapya.com)
Editing parameters (okapya.com)
Any help or suggestions much appriciated. Great Addon, thanks.
Hi Jason,
I am a developer from Checklist for Jira app, I will try to help you with that.
To answer your main question, there is no permission rule condition that targets the user who created a certain checklist item. This would be useful to achieve your goal, but unfortunately we do not store the user information so we are not in a position to implement this at this time.
As you noticed, items imported from a template becomes local items. By default, those items can then be deleted. If you were using Global Items, those would not be delete-able. Global Items are configured by administrators in the custom field context, and do not come from a template.
If Global Items don't fit your situation, you could also create two different checklists, one that is not editable and is loaded from the template(s), and another one that allows creating local items.
We have in mind to eventually store information about the user who creates items, this way we could then add a permission condition on it. Although I cannot promise anything.
I hope this helps!
Kind regards,
Maxime
Hi Maxime,
thank you very much for your time and your answer.
However, could you please clarify onr point...
You said
"If Global Items don't fit your situation, you could also create two different checklists, one that is not editable and is loaded from the template(s), and another one that allows creating local items."
by 'create two different checklists', did you mean setup two Checklist Custom fields?
one that is locked down by permissions, and one that is not?
Therefore, two checklist Custom fields would appear on the Ticket/issue.
Once again, thank you very much.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Jason Thompson,
That is exactly what @Maxime Lefebvre _Okapya_ suggested.
By setting up two distinct Checklist custom fields, you can handle both scenarios where:
Depending on how you display checklists in your issues (the Display Mode parameter), you could either find two custom fields in your issues, or both checklists inside the same panel (if you use a Panel display mode).
I hope this answers your question!
Kind regards,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Maxime Lefebvre _Okapya_ & @Pascal Perreault _Okapya_
Thank you both for your time and knowledge.
I will discuss the options with the Checklist users, and I am sure we can come up with a good solution.
Great Addon.
Kind Regards ...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.