when I select issue type. I need to filter custom select list values based on customer

[wajdhaikal]

Is this possible?

Can I use cascading select technique wiith native fields, or this feature only works/maps between custom fields only

[wajdhaikal · Accepted solution]

Thank you all 'Nic Brough' and 'Alex Taylor' , actually I'm going to go for option number one Nic suggested, because it seems the best or closest solution for my current requiremenmts. we are dealing with customers who has only one login account in JIRA , just I want to separate he issues a single customer logs from other customers under the same support project so each one can see thier own submitted requests and no body can see other issues related to other customers.

but tell me because Im new o JIRA and I did not find the "reporter browse" permission?

[wajdhaikal]

I will change he title to a better one reflecting the context we are talking about

[Nic Brough -Adaptavist-]

That's at http://confluence.atlassian.com/display/JIRA/Current+Reporter+Browse+Project+Permission

[Nic Brough -Adaptavist-]

I'm afraid the question doesn't make any sense to me.

Could you explain differently? I understand that you want to select an issue type, but what does "filer (filter?) custom select list values" mean? You want a different set of options available for a select list based on the issue type? If that is a good guess on the meaning of your question, then that's easy - look up "field context" in the documentation, you'll find you can have a different list of values for project and/or issue-types.

[wajdhaikal]

yes 'Filter'

[Nic Brough -Adaptavist-]

... and the rest of the question means?

[Alex Taylor]

I believe he's asking if it's possible to have a cascading select-list where one or more of the lists is a System field rather than a Custom field. I have an interest in the answer to this one myself :-)

For example: we plan to define a Security Level for each of our customers so that a customer can only see those issues they raised themselves. In effect, the Security Level field on the Create Issue screen will then function as a 'customer picker'. Now, since we already know which of our products each customer has, we would like to auto-populate certain other fields, both System and Custom, on the Create Issue screen - 'Product', 'Version/s', 'Primary Contact', and so on - with the appropriate values for the selected Security Level (aka 'Customer').

Currently I think the only way to achieve this may be to use a cascading select-list with the top-level list being 'Customer'. The Security Level field would then not be displayed on the Create Issue screen at all, but would have its value assigned from a post-function. This does however have the drawback that the 'Customer' select-list must have the exact same set of labels as the Security Levels for the Project. It would be much simpler if the top-level list could *be* the Security Level field :-)

[Nic Brough -Adaptavist-]

Ah. Then the answer is "no". You'd need customised plugins to do this.

For your situation, I'd actually do one of two things

1) Use the "reporter browse" permission - when used in "browse permission", it does exactly "a customer can only see those issues they raised themselves" , but it's not suitable when "customer" means "a group of people who all have different Jira accounts". Atlassian use it themselves - if you log a support call, you'll be able to see it, people you include can see it, Atlassian can see it, but no-one else.

2) Pretty much what you've just said - code a security level thingy that works out the actual security level based on something the user enters. If you're coding that, I'd be tempted to go a step further and code it by user group (because your customers are going to be groups to identify their organisational relationship, right?). Have code that says "read list of security levels, and if the user is in a group with the same name as a security level, set it to that". Possibly ;-)

[Alex Taylor]

Yes, that's the direction I'm heading :-) The proposed security model is:

- 'Browse Project', 'Create Issues', 'Edit Issues' and 'Comment on Issues' will be set to 'jira-users'

- a Security Level will be created for each customer, and the Group containing that customer's users will be added to it

- issues raised by a customer's user should then hopefully be visible only to that customer's users (plus us, of course!)

It does sound like the best option is to hide the Security Level field and set its value from a post-function. Not too difficult to implement :-)

[Mizan]

Hi Alex ,

Even i was doing something similar(Post Function to set Security Level) .Hope you find it useful