JamieA Expert

This is available as one of the built-in scripts in the script runner plugin - Transition parent when all subtasks are resolved. As you say you put this as a post-function on the sub-task workflow. You can specify which transition to use on the parent issue and which resolution to use. It can also be used as a listener.…

> "Client does not have permissions to send as this sender" Possibly you are in a corporate environment and the mail relay does not allow sending mail from a particular address? I'd speak to your mail admins. That message is not coming from JIRA or the plugin.

> Examplemacro.java This makes me think you used the confluence, and not the jira archetype? But it doesn't make a great deal of difference, Nic is right.

They're broken again... any chance you could do your thing again John?

Fantastic, thanks John.

Yes, that would be the easy, sensible solution. I see that since I asked the question they've disabled the plugin module which I guess is an improvement.

OK, good to hear. Thanks John.

I do. The information required in the marketplace is the same as in PAC. Anyway, at least, they could replace the output with "deprecated" rather than a huge stack trace, which makes people think confluence is broken.

I would remove the store, and just move the post-function to the top of the list.

Any errors in logs? What type of field is it?

This is an extremely common use case for Script Runner... on your transition put the following custom script post-function FIRST: import com.atlassian.jira.component.ComponentAccessorimport com.atlassian.jira.issue.MutableIssueMutableIssue issue = issuedef customFieldManager = ComponentAccessor.getCustomFieldManager()def…

No, and although there might be some hacks available, they won't be possible with the hosted version. You should change your workflow so there are anywhere->anywhere transitions but with conditions such that only administrators can do them.

Have you associated it with the issue type? Is it on the view issue screen? Check with the "where's my field" thing. Also check the logs to make sure it's not failing.

Heh, no problem.

I just wrote the script below and applied it as a validator on the Create transition and it worked as expected, ie it blocked me when the user in the custom field exists and is in jira-users, and it allowed it when the user didn't exist. To say again, have you published your draft? Any time you make changes to the groovy…

That really should work (if you tested the script in condition tester) ... are you sure you have published the workflow, and that the project is using the correct workflow? I see that the workflow is currently in draft mode.

OK... so a validator won't fire until the user has typed in all the fields... which is less than ideal. Sorry to ask, but can you click Edit on that validator and attach a screenshot of that?

Is this a validator or a condition? They are two very different things, but you are talking about a "condition validator". Could you post a screenshot of this appearing the list of conditions or validators in the workflow? ta.

Hi... This line: def issue = componentManager.getIssueManager().getIssueObject(issue.key) is redundant... the issue is already provided to the script. You're returning a string... I thought you were using the "simple scripted condition/validator"? If so you need to return a Boolean, so just return true/false, depending on…

Hey... println will go to your catalina.out log. You should just remove your if/else and make the last line: return groupManager.isUserInGroup((customFieldManager.getCustomFieldObject("customfield_13100").getValue(issue)),"jira-users") But you also need to check for nulls and stuff... maybe try to break that line into…

It's not a static method... use: def customFieldManager = ComponentAccessor.getCustomFieldManager() customFieldManager.get...

I'd suggest you just use a short text and do an AD lookup on that, because you won't be able to use a user picker as you say. I'm away for a bit now, will try to help when I'm back. jamie

Hi F... hrm, no idea. What context are you running this in... is the validator called "simple scripted validator" ? If so then issue should be defined. You don't need all those imports - in fact the only one you need is ComponentManager.

You need to use ComponentAccessor.getUserUtil() and use that to see if the user is in a group. User has no "inGroup()" method. There are examples with this on this forum somewhere...

Marked as compatible. Thanks @Thanos Batagiannis [Adaptavist] for testing it.

Can you give me more details on how it doesn't install? Perhaps messages from the server log file. Also, if you see it in UPM then it must be installed.If you don't read English please create a ticket at https://productsupport.adaptavist.com/servicedesk/customer/portal/2 and I'll hook you up with a German colleague.

Cool. One piece of advice... I think it might be better to append all the custom field values you don't want to keep to the description. You can use wiki markup to put them in a nice table.

Doing it with a service is fine, it's the "proper" way. My way below is the quick and dirty way. You can wrap your code inside the issues loop in my example if you prefer.

Your going about it right but you have a way to go... here's some code to get you started. Requires testing, and error handling: import com.atlassian.jira.bc.issue.search.SearchServiceimport com.atlassian.jira.component.ComponentAccessorimport com.atlassian.jira.jql.parser.JqlQueryParserimport…

You don't want to be modifying IssueImpl...