JamieA Expert

Couldn't agree more. Even my administrators do this! But once created, you should optionally be allowed to delegate mgmt of values to any user that is project admin in all projects assoc'd with the relevant field context.

Wonder if anyone would actually pay for a "user-managed select list" field... or would it be another of those things that people resent paying for because they think it should be in the core product (under the category of federated project admin, which it should).

it's easier if you would comment on answers rather than creating new answers. Please could you check your javascript logs by pressing f12? It might be easier to give them to us privately which, you can do by raising a ticket at https://productsupport.adaptavist.com/servicedesk/customer/portal/2

can you try with the import: import com.onresolve.jira.groovy.user.FormField

Try disabling then enabling the plugin...

If you want to use behaviours, there are examples for setting valid select list options here: https://scriptrunner.adaptavist.com/latest/jira/recipes/behaviours/setting-default-fields.html#_setting_defaults_for_selects_etc So you add a behaviour to the first select, which will set the possile values for the second select.

Just to add to Jozef's answer. You can put them anywhere that is accessible by all your hosts, eg NFS mount. Either sym link that to the home/scripts dir, or set a new script path in system property. Or, morally the same, have all your scripts in VCS and something that checks them out on all the instances. Script…

No worries. CA and CM do the same thing under the covers, but CA is @PublicApi, CM is not. One day... probably a very long time in the future, CM might be removed...

This was duplicated to a support request. Let's work it out there and we'll update here when resolved.

In your configuration is Epic Link a required field? Copy project, when it copies issues, deliberately does not copy the epic link. It creates new epics and links the issues to those. I don't see how you can work round this other than (temporarily) removing the requirement to enter the epic link.

It's pretty much essential to Atlassian's business model that the plugin developers are paid. If not, people get bored and stop maintaining their plugin, which makes the Atlassian tools look bad. Atlassian want their products to be a platform for other excellent products (eg Balsamiq), so you get locked in to them. To do…

As Alejo said, we changed the styling for the next release. But that view is not for editing - you can use the "note" field so you can know which field to edit...

Sorry, I meant that I advise you to create a support ticket, and then post back here if you get useful information.

I would create a support ticket, I'd be interested to hear what Atlassian support say about this. Sorry not to be of more help.

I think your user membership attribute is wrong, I don't see how it could be uid. It should be memberOf or something. Try unchecking that option.

Hrm I have the full DN for the users - perhaps it needs that? And do you have the revese lookup working, such that if you look at the ldif for a user it shows the groups they're in? I guess that needs to be tree if you have that checkbox checked. I'm afraid I'm out of ideas, so you might need Atlassian support. But I…

What does the ldif for a group look like. does it have attributes called memberUid? My settings are: Group Members Attribute: uniqueMember and the checkbox unchecked. You may have your openldap set up different from mine of course, so only looking at the ldif for a group will tell us.

How do you mean "member-Attribute"? AFAIK the member attribute for OpenLDAP is uniqueMember. If you have member, you need to change that in in Membership Schema Settings. Can you double-check the actual attribute in your schema, and the settings in jira.

Unfortunately not at the moment. Although we could exempt that field from jira's dirty form checking (I presume) I'm not sure how to do it reliably, and so that you get the warning if it has been previously modified, which is why it hasn't been implemented. Is it a major issue? Anyway, I…

The time it takes proportial to the number of commits, as it gets the log for the entire repo to index it. The only way I've seen of gauging how long it's going to take is by upping the debug level for that package and looking in the logs.

Just ignore static type checking, I don't think it can handle @Grab.

Why not? It's the Answers project on jira.atlassian.com.

If you think it's necessary, you should create a feature request here: https://jira.atlassian.com/secure/CreateIssue.jspa?pid=12290&issuetype=2&Create=Create

The second param should be "is Epic of", see https://jamieechlin.atlassian.net/wiki/display/GRV/Scripted+JQL+Functions#ScriptedJQLFunctions-MoreComplexExamples The first param should may be "Team = A and issuetype = Epic'

Don't worry... I think a lot of us forget that this stuff is probably a lot harder if English is not your first language.

OK, that makes sense Mark. I don't think it's entirely the same though because a version ID is an inscrutable Long, whereas a user key looks identical to a user name. But again, my example of JQL is not a good one because as you say, other JQL clauses break if you change the display name of the thing you're querying on.

The key is actually the same as the username, until the username changes. So are the Atlassian team saying that JQL won't work for users with changed usernames? I'm sure that's not the case...

I think this is a separate question, you will have better results starting a new thread, because people will often not look at answered questions.

You need to override getConfigurationItemTypes on your customfield type. Have a look at the code here, it's pretty straightforward - https://bitbucket.org/jamieechlin/issue-alternative-assignee/src/c83e17f19000/src/main/java/com/iamhuy/jira/plugin/customfields. Also the (freely-available) example code for Matt Doar's book…

You'd have to start a new thread... but it seems like a bad solution. new Thread({ // do stuff}).run() Why might the email fail to be sent? Why does it take 12 minutes to get there? If you must do this maybe consider using a service: to run every 10 mins and check the error queue, making sure to remove it from the queue…