Comments
-
The problem we've established is that you can only view avatars if you have authenticated to jira. This will only work seamlessly if you're using SSO and probably Outlook. IMHO this is a bug... the easiest solution is to modify com.atlassian.jira.avatar.AvatarServiceImpl#canViewAvatar to just make it return true, which…
-
It would be criminally negligent not to backup your data, however whether they make it easily available is another matter. No doubt they will be here to say so soon. If not you can take backups yourself with rsvndump, included as standard in subversion 1.7 IIRC, but also works with 1.6.
-
issue.originalEstimate = 0 // IIRC They may be related to the column names but the javadoc is the place to look. Also you should probably start a new question for this, not many people will look at answered questions.
-
Yeah... it happens ;-) Try to get into the habit of using some log.debug statements and change your log level, then you can see easily what's getting returned.
-
You should be able to do: issue.description = cfValues["Name of custom field"] Use the name of the CF, not the ID. It should work from memory, but not tested... LMK. BTW your way should work but you need getCustomFieldObject not getCustomFieldObjects. The plural form returns a list.
-
You need to make sure your (old) osuser.xml is present when you do the upgrade. This will create the new directory based on the contents of osuser.xml, but more importantly it will migrate users from the internal directory to the new "delgating ldap" directory. If you didn't do this, contact support, they probably have a…
-
can you attach a screenshot?
-
Also that never returned a string, that could never have worked, it would always have returned false. You want: "DevEx" in issue.components*.name
-
This is the correct answer... if the custom field type is a List, you need to use contains, unless you are testing for list equality. But the key point is to: log.warn cfValues["External Customer"].class Then you can see the type that you are getting.
-
getDurationString should return you a properly formatted duration... Best thing is to return a Long then use the template as I originally recommended. I don't think the search will work though. Try all this with no searcher.
-
Set the searcher for the field to None then, but it's best if you can upgrade so you can using the duration indexer. You didn't answer the question about whether it was there by the way.
-
Change the searcher for the field to Duration, as I said in my answer. If you don't see Duration you might be using an older version, if so which one?
-
OK: import com.atlassian.jira.component.ComponentAccessordef changeHistoryManager = ComponentAccessor.getChangeHistoryManager()def items = changeHistoryManager.getChangeItemsForField (issue, "status").reverse()if (items) { return ((new Date().time - items.first().created.time) / 1000) as Long}else { return ((new…
-
You just want the time in the current status? Then you just need to subtract the first change item returned from the current date.
-
Can you elaborate on "How i can show up days count of last transition". Why did you post that code, is that what you have tried?
-
Do you know how difficult it is asking the corporate bean counters for a pass to go to AMSTERDAM?! A boring German city is much easier to get the green light for ;-)
-
If you add the plugin's label the right people are more likely to see the question. Untested, but to check for a comment this should work: transientVars.get("comment") so: !(cfValues['String Custom Field'].getValue().contains('Bar') || transientVars.get("comment") should require a comment when String Custom Field contains…
-
I truncated the stack trace, because there was nothing useful in it and it tends to put people off looking at the question, and scrolling down to any answers.
-
What version of jira and of the plugin? When you say "fixed ordered list", by what would it be ordered? There should be more to this stack trace, like a "caused by" section...?
-
You are going to struggle with that because the behaviours reference the IDs of custom fields. If you click Edit by the behaviour you can edit it as XML, which is how you would move them from one instance to another.
-
This has been fixed in 4.3.8 and has been released, or 4.1.3.18 for JIRA 6.
-
I had this problem recently... I think if you run it in the debugger you can fudge things and get logged in, but this is quite tricky. The easiest thing is for you to ask the people that made a backup to temporarily create a local user directory with a user name and strong password, put that account in the system admin…
-
You just do as I did, which is only run the validation if the field has a value. Let's say the value is assigned to a variable called value then: if (value) { // do validation }
-
So you've created a behaviour, you've added a field, and then a server-side validator. You can just paste the script in to the big text box rather than modifying Sample or ScriptSample. This is the easiest way to get started. 1) Change the code to def is8 = !f.getValue || f.getValue() == 8 But experiment, and do a tutorial…
-
This won't work if you're trying to do what I think you are, because the issue won't be indexed with the new value until it's committed. Instead change to a "simple scripted validator", and use the condition: issue.getOriginalEstimate() Which is short for issue.getOriginalEstimate() != null && issue.getOriginalEstimate()…
-
I don't know how to do it via CSV import, but the script runner can import cf values for cascading selects, just by indenting them in the input: https://studio.plugins.atlassian.com/wiki/display/GRV/Built-In+Scripts#Built-InScripts-BulkImportCustomFieldValues May be helpful.
-
I'd just write a custom post-function and hardwire the mapping of components to groups. The component leader will always be a part of multiple groups, eg jira-users, so doing it programatically would be messy.
-
issue.issueTypeObject.name == "MyIssueType" && ComponentManager.getInstance().getUserUtil().getGroupNamesForUser(issue.reporterId).contains("somegroup") But if you allow anonymous creation of issues check you have a reporter, otherwise you'll may get an NPE.
-
Your answer was so good it's worth saying twice ;-) For some reason the delete doesn't seem to work.
-
I have been through this tutorial and found it helpful: https://developer.atlassian.com/display/DOCS/Incomplete+Plugin+Tutorial+-+Writing+REST+Services Says incomplete but I got what I needed from it.