change security levels

[David Mora]

Can security level visibility be changed such that any user can see and change the security level of an issue?

[Nic Brough -Adaptavist- · Accepted solution]

Absolutely not. That would break the security, rendering the security level system utterly useless.

[David Mora]

I understand all that but the problem I'm having relates to the visibility of all the other security levels. Right now users can change the security level of an issue to those that they have access to. They cannot see security levels that they are not a part of. I want to know if I can make it so that all the levels are viewable by users.

[David Mora]

Sorry, I think I wasn't clear. I meant to ask whether or not the code could be changed such that the security level field is viewable by anyone who has access the the issue. This way the issue can be changed to any other security level. This doesn't mean that the issue would be viewable by all. Only the different security levels will be viewable by all.

[Nic Brough -Adaptavist-]

Ah, I see.

You don't need code change, just put the field on screen. If a user can see the issue because they match the security rules, then they will see the security level field as part of the standard display. To change it, they must have the permission to change security levels though (it won't show on edit/update screens if they do not)

[Jose M.]

In general, regarding the administration around Jira, visibility can be provided only through an additional documentation along with Jira's customisation.

[Nic Brough -Adaptavist-]

Hmm. No, and you don't want to either.

On a technical level, you could do it with some code hacks.

On a security basis, it's generally frowned upon - a user does not necessarily need to know that there are other levels of security and in most cases, shouldn't need to be able to use levels they don't belong to. Although it's not a huge issues because the data that needs protecting is still protected

On a human level, no, it's a disaster. I implemented a work-around for it. Our security related calls went from maybe 2 a year to over 300 a month just handling the "I put the wrong level on my issue", "why can't I see things I created", "why do I keep getting permission denied when I create things" daily calls, which was unworkable because we then had to go to find users who were in the right levels to get them to unpick the errors. Education damped it down a bit, the "why" stopped, but we were still wasting vast amounts of resource correcting the mistakes. After three months of hell, we persuaded our managers to remove (mostly with the costs of "you need to hire two more people to sit there fixing the mistakes").

Short answer is even if it's ok to tell users about other security levels, you should NEVER let them set levels that they don't belong to because they will get it wrong.

[David Mora]

Nic, I agree with you completeley but in my case this solution is the only option I have. I am not using this system for a traditional help desk environment. I need a system different engineers can use to work with each other. I have different groups that work together but yet need to have privacy between each other. One group will open a "ticket" that will go to group A to work on and they way I am making this work is by making a security level for each group and adding that group's members to the security level. That way only the people of that group can see the ticket. From there if the ticket needs to be "transfered" to another group so that they can work on another part of the ticket all that has to be changed is the security level to that of another group. This is why I need to make it so that anyone working on Issues can see all the different security levels.

and even if they set the wrong security level, then the group who gets it will realize it's in the wrong queue and they will transfer it over (by changing security level) to the right group.

I am trying to find a replacement for a system we have now and I thought JIRA might be the right one but I've run into this issue. I thought about having different service desks(projects) for the different groups and that will solve the security issue. Transfering tickets would just be a matter of moving and issue to another project and I wouldn't have to worry about losing information because all the different service desks would have the same issue types with the same fields but the problem I have here is that there would be N amount of customer portals for N amount of Service Desks. I only need one that can submit issues to the different service desks depending on which group needs to answer the ticket.

[Nic Brough -Adaptavist-]

Ugh, dynamically hiding things like that is a recipe for confusion, but I suspect you know that.

The closest I can get you without code change is roughly what I described before (i.e. the one that causes 300 problems a month) - I didn't do quite this, but create a custom field with similar/same named options as your security levels. Then find/write a plugin which can bypass the "you can't set security levels you aren't in" restriction and copy the value into the security field.

You'll need a listener if you want to allow it on edit, but a more simple solution is to actually encode it into the workflow instead - each team has a set of status, each change of status sets the appropriate security level (you can use post-functions for that)

[David Mora]

Thank you very much for all your help. I will try to figure it out using workflows but if that doesn't work then I will have to resort to creating a plug-in to bypass the restriction and copy the security field from the custom field. One last thing: Regarding workflows, do they support decisions? meaning Status A can go to either Status B or Status C depending on a variable like a yes or no question?

[Nic Brough -Adaptavist-]

No, a transition, by definition, only has one end point.

What you do is create several transitions, and protect them with "Conditions". These can do things like "user is in role X", "Field Y has value Z in it", and a condition will hide a transition if the condition is not met.

[David Mora]

I'm trying to make it so that the ticket can be "transfered" at any point of the workflow. So for this to happen, I would need there to be N amount of transitions that connect to M amount of Status where the condition for each transition would be whether or not the security level has been changed to X. That would mean that every workflow would have n^m different paths that could be taken. and that can be very tedious to create and very complex to view.



EDIT: I guess it would be (n-1)^m different paths

[Nic Brough -Adaptavist-]

Not quite, a transition can be reused, as only the end has to be in one place. So the simplest case is M number of Status with just M+1 transitions - one into each status from any or all of the other status, plus the initial "create" transition.

My maths is a little rusty, but I agree that (n-1)^m +1 is the second worst case, with loads of unique transitions doing different things (I added 1 for create here as well). But you can also create transitions from a status to itself, and you can create more than one transition from one status to another - very ouch.

[David Mora]

Okay thanks and I'm still having trouble understanding the way workflows work in JIRA. I am new to it and previoulsy I had always thought of workflows as being a graph that shows the different paths that can be taken. Each level of the path is another stage (task). At each stage (level) the person servicing the ticket would recieve pre-written instructions telling him/her what needs to be done at that step. Here in JIRA workflows are configured as statuses and transitions and I understand that the work to be done is in the transition phase(correct me if i'm wrong) and after the work is done it leads to a status that the ticket is in. But where do I write the instructions for the person servicing the ticket? I can write it in the description of the transition in the workflow but that would mean that the person servicing the ticket would need to open up the workflow and view the description of the transition one at a time. Also, some of those transitions would depend on answers to some questions. For example, for one of our workflows, It requires that the person servicing the ticket check the active directory to see if the requesting user already has an account. Depending on that answer the workflow will go either down path A or path B, but I want it so that at each transition of phase of the workflow the person working on the ticket is prompted with the relevant questions and given the proper instructions to follow. Is this possible at all with JIRA. I want to make sure this product has everything I need before I convince my boss to purchase. Thanks again.

[Nic Brough -Adaptavist-]

Mmm, not really.

A workflow is a process something passes through. A status is "where the issue is" and the transitions are an action that change the status. There is no "transition phase", the transition starts with a status, and ends with one, an issue is never part-way through a transition.

You don't usually put instructions in an issue tracker - instructions should be part of a well documented process, not part of each individual task.

You are right about the routing idea though. Using tour AD example, I would imagine the list of status could be

• Open (new item, no-one has done anything yet)
• In progress (one of the AD engineers is going to deal with it)
• Done (the AD engineer has checked AD and then dealt with it because they can. End of path A)
• More information (the AD engineer has checked AD and found a problem. Path B)

Transitions between each status can pop screens asking for more fields, comments and so-on. I'd probably use links to confluence on those screens to give people standardised instructions. For non-standard exceptions, ask for it in the description field or other text based field when it's originally created, or when you feel the need to add them.

You could easily invisage this as a post-it note with "I want" written on it. Engineer picks it up, works on it, puts it in the "done" pile or hands it back for more information.

[Jose M.]

If any user would be able to see and change the security-level of an issue, so it would be wrong to talk about security here, since a security-level means to show or hide issues from some users. Maybe the matter is more about permissions and roles and also conditions in the workflow, who is allowed to perform which transition, etc.

[David Mora]

I do want to hide issues from certain grous of people but I don't want to hide the different security levels. Showing the different security levels does not mean that the issues themselves will be seen. The matter was originally about hiding issues from different groups but yet allowing tickets(issues) to be transferred to those other group(s). Being that JIRA does not support this as an out of the box feature, I decided that creating different security levels for different groups would work as a workaround. That way each group belongs to its own security level and they can only see their own tickets. But lets say that there is a ticket I am working on, and it requires another group to complete their part before the ticket can be closed. I would then transfer the ticket to their group so that they can see it. At this point, I would just select the security level and switch it to that of the other group and effectively "transfer" the ticket because then I wouldn't be able to see it but they would.

[Jose M.]

If you mean: Project AB with Members-Groups A and B. Security Scheme AB with Security-Levels A and B. Level A = Visible for Group A, Level B = Visible for Group B. Permission to change Security-Level given to A and B. Members from A could change the Level to B and pass the ownership to B. Members from B could do the same towards A. Yes, that could work.

[David Mora]

That is exactly what I need. How can that work? Right now if I give Group A Security level A then Group A can only change the security level to None because they cannot see Security Level B.

[Jose M.]

Do both groups A and B have the permission to change the security-level? I would expect, while viewing the issue, A should be able to change the Level to B. But I am just thinking about, if levels are handled like groups and you have to be a member of that "group" or "level" in order to see it. I hope not.

[David Mora]

Yes they both do but I do believe both groups need to be added to that security level in order for the levels to be seen. Is there a plug-in available that bypasses the "cannot see security issues I am not a part of" function?

[Jose M.]

In addition to my previous answer, please consider use as workaround also a Level AB where both groups are in. So A or B could pass the issue back to the joined level AB, along with a comment, and the other level could take over the ownership. Of course, this is somehow similar to security-level none.

[David Mora]

Would work but not time effective. This is simple when there are only two groups. Having three groups requries Security Level A, B, C, AB, BC, AC, ABC just so it can cover all the different possibilities for ticket transfering. Now imagine how many levels would be required for 10 groups?

[Jose M.]

There is something needed, where all groups can access all levels but without access to the issues. If the jira-users group includes all users and would be added to all levels, so all users would be sharing the same levels, but not the same projects, where only defined groups are in. Sounds maybe a bit strange.

[David Mora]

Thanks. How do I create my own condition in the workflow transitions? I have one status with two different transitions coming out of it. The transition will either be one or the other, never both. I want the conditions to be set of a question that is promped on a screen to the user. How can I set the conditon? I looked through the list of available conditions and none of them fit my needs.

[David Mora]

Yes, that is exactly what I have been asking. Is there a plugin available? Or would I have to be the one that creates on from scratch? Thanks

[Nic Brough -Adaptavist-]

You aren't going to be able to create a plugin that does this.

The security level field is built into the core of Jira, you can't replace it.

Your options are to hack the core (basic advice on that is "don't") or to go around it. My previous suggestion is your best approach - create a parallel field that has all the security levels named in it, and then you can code a listener or post-function that updates the security level based on the content of that field.

I've not seen a plugin that will do this (probably for exactly the reasons I already mentioned), but I'm pretty sure you can do it in the script-runner plugin.

[Jose M.]

Basically the problem is because of the incorrect functionallity with the permission to set the security-level. It should not be connected to being a part of the level. This is a Bug in Jira.

[Nic Brough -Adaptavist-]

Ah, no, it is definitely not a bug. It is done by design, and it's the right design.

In almost all security use-cases, a user should not be able to set the security level to a level that they are not in. In a small handful of cases, a user just being able to see the other security levels is a security breach in itself. On a more general level, it's an absolute disaster in basic UI handling that a user can do something that blocks their access to what they've just been editing.

It's very clear that this is not a bug, it is the correct handling of security. It won't suit everyone, but it is the correct starting point - secure first and the admins have to think to downgrade that security.

[Nic Brough -Adaptavist-]

Most of us add more plugins to provide the conditions we need. I'd always install the Jira Suite Utilities first and see if that can get you closer (actually, that's a recommendation I'd make no matter what the question is - I pretty much refuse to do any work on a Jira system until it's installed. It's free, and so horribly horribly useful I'd have written most if it myself by now if someone hadn't done it for us)

Next, I'd check the marketplace for other plugins that provide conditions. I generally land on "Jira misc workflow extensions" in a lot of cases. But I usually end up on the plugin that is fourth on my "plugins you really should add to Jira" list - the script runner.

The trick for your use case is two similar transitions, but with inverted conditions. For example, on transition 1, set "only people in role A" and the other "only people in role B". Of course, that is over-simplistic, because you could put one user in both roles, but as I understand your need, that won't really happen. And it is just an example, if you've got the script runner, you can easily put in conditions like "user is in group X" on one transition and then "user is not in group X" in the other.

One caveat - the script runner allows admins to write and run code that can damage Jira if we've not got a good grasp of how the internals of Jira work. You'll be fine if you stick to the built-in scripts and examples, but if you write your own scripts, then just bear in mind that you should test them extensively before using them in production (well, if they write data, definitely, but if you code a validator or condition script, they should be read only. So the worst case for a read-only script is a log file full of junk and the inability to transition an issue until you fix the script)

[Nic Brough -Adaptavist-]

No. It's totally different. Although they share the good design principle that you don't let users create stuff they then can't see because it's utterly wrong for the way humans think and causes you massive support problems.

[Jose M.]

Well, I really wonder if the "Level" is basically handled the same way as a "Group". If so, the design would be a quite simple one. Remember the problem with sharing filters: even the Admin has to belong to the group sharing the filter. I see here the same problem: User A can see the issue while it is at Level A. And User A belongs to the Project and has the permission to change the Level. So why prevent him to do it?

[Jose M.]

mmh. If a Level states, that a participant is able to see an issue and work on it, so the user - as from my head -, can remove himself as participant. Afterwards he won't be able to see the issue. Here not the Level was changed, but the condition to access the issue. In this princip I would expect it to work.

[Nic Brough -Adaptavist-]

That really is a terrible way to configure it - just because Jira lets you do something doesn't mean it's a good idea. This is the sort of thing I spend time removing when I get called in to sort out Jira problems.

Don't use dynamic roles in security levels, it's a disaster for the users.

[Jose M.]

Hi David.

After all the discussion, in my opinion it is not possible to handle it satisfyingly through security levels.

But I imagine it solves your problem, to use an Agile Board with a Simplified Workflow. Having the plugin you can handle it very fast. You could use different columns for the different teams i.e. groups. You would have issues in the Backlog and everyone would be able to move an issue (card) to another group i.e. status. The Agile Board would visualise where the issues are.

[David Mora]

So I added post functions that would copy a custom variable to the security level and that fixes the problem of not being able to see the different security levels but I have a potential problem. THat post funtion will only run when the workflow transitions to another status right? Can I make it so that the security level changes as soon as the custom field value is changed(without having to change the status of the issue). Thanks

[Nic Brough -Adaptavist-]

You can do that as a "listener" instead - same basic code for the update of field, but a listener listens for events. "Edit issue" is a standard event fired when you update an issue without a status change. I tend to do a complete conversion - get the listener to pick up all events that might change the field, including transitions, and then drop the post functions (easier to debug if you know you're doing the update in only one piece of code)

[David Mora]

How would I go about creating a "listener" are there some online tutorials or documentations? Do you have some samples I can work off to create my "listener" function?

[Nic Brough -Adaptavist-]

I'd use the "script runner" plugin - it'll save you all the work of creating a post function. You'll still need to write the code, but not a lot, and the script runner has lots of examples in it

[David Mora]

I can't find an example that helps me. Where can I find the keywords for JIRA? Keywords meaning variable names. I need to know the variable name for Security Level's in JIRA and I also need to know the variable name for my custom field. I need those two but I need to set up the script to "listen" for when my custom field is changed to another value. I know, these are beginner questions, but I have no experience with Groovy nor Java.

[David Mora]

Actually I am completely lost. I have no idea where to begin. Don't know what I need to download or where to write the script or where to save it.

[Jose M.]

Please consider what you really need and the best steps to achieve it. If you do not have advanced knowledge, how to configure and costumise Jira, I would not start scripting.

[Jose M.]

Regarding a previous question about workflow, steps, transitions, conditions, if you are in status "unassigned" you can offer transitions to Group A and Group B. Both groups should be able to perform the transition to A or B. Afterwards only members in the target status should be allowed to work on the issue by restricting the condition to they group.

[Nic Brough -Adaptavist-]

The core of the code I think you need for the script runner is below. The id of the security level is up to you, you need to read your security scheme to find it (hover the cursor over the link to "edit" each security level in the scheme and you'll see a url that contains "id=4" )

def myFieldName = "A custom field name"
def id_of_security_level = "4"
 
def componentManager = ComponentManager.getInstance()
CustomFieldManager customFieldManager  = ComponentAccessor.getCustomFieldManager();
CustomField myField = customFieldManager.getCustomFieldObjectByName(myFieldName);
 
def myFieldValue = issue.getCustomFieldValue(paidDaysField)

if ( myFieldValue )
    { 
    issue.setSecurityLevel(id_of_security_level);
    }

I still think the original requirement is shonky though - hiding stuff just because you're not assigned it makes it hard to see what's going on or what you have done. It's far better (and requires no code) to simply leave things in plain view and just say "only assignee can update"

[David Mora]

Thanks. For user permissions, how can I configure the permissions so certain users cannot see all the projects. I want certain users to only be able to see one project(service desk).

[Nic Brough -Adaptavist-]

You need to re-work the permissions - have a group for "can log in", and don't use it for anything else. Don't put the restricted users into roles in projects you don't want them to see, but do add them to projects you do want them to see.

[David Mora]

Hey Nic, Is there a way to have a watcher or a participant have permission to view/edit an issue regardless of the security level or the project the issue is moved to? for example, lets say issue A is in Project A and has security level A. I become a watcher to it because I have all the permissions and then the ticket gets moved to another project and/or gets its security level changed to that which i am not a part of nor have permission to. Can I still be a watcher to it? Or can I get CC'd on the issue so I can get all the notifications of the issue through email? Thanks, David

[Nic Brough -Adaptavist-]

Sort of. This is a slightly more advanced usage, but it'll work. You could add "participant" from the Jira Toolkit as a user in the security level. Or, you can add a specific "user picker" field called something like "cc" and actively put people in there (and use it in the security scheme too)

[David Mora]

Thank You Nic. You have been very helpful. Is there a way to get the HTML files for JIRA? I just want to do some UI changes to the Customer Portal. Nothing computation, just heading sizes and extra links and what not. Thanks, David

[Nic Brough -Adaptavist-]

Jira doesn't have a lot of html, it works mostly with JSP, Velocity and Soy. You'll need to dig around in your installation to find them and edit them.

[David Mora]

Is it advised to not touch any of that code?

[Nic Brough -Adaptavist-]

Generally, yes. Unless you're highly familiar with it, you don't know what you might break. Code hacks are a pain on upgrade. And you are unsupported by Atlassian if you use them.

[David Mora]

oh okay.. I think I may have found a bug in JIRA. I am working with custom security levels within a Issue. I have X amount of different groups and X amount of different security levels that pertain to each one of those groups. This means group A can only see issues with Security Level "None" And Security Level "A" and the same with every other group. I have also created a custom field that allows individual users to be selected. I have added this custom field to every single one of the different security levels. I have called this field "CC". When creating an issue I can set the security level and choose any users in the CC field without a problem and the chosen users can see the issue. The problem is if I want to add users after the issue has been submitted. Once the issue has been submitted and I try to add users to the CC field, I get an error stating "Users do not have permission to browse issue: X user, Y user" How can they not have permission when I am able to add them on issue creation?

[Nic Brough -Adaptavist-]

When you are creating an issue, the security level is not set (this is not a security risk because the data only exists on the user browser until it's committed). Once it's created, Jira is able to read the security level and see that they don't yet have the rights to be added. To me, that does sound like a bit of an issue - I'd expect to be able to add users to a cc fiel.

[David Mora]

It is a problem because i have added the custom field "CC" to the security level and I still get the error. Is there a certain precedence that takes place in the rules? As of right now I only have two rules in each security level. One is a group (Group A) and the second is the custom field (User picker) "CC". I thought the order in which the rules were displayed mattered to I moved them around and I still have the same problem.