PD Sheehan Expert

There isn't really a one-stop-shop place to learn everything if you have no prior coding knowledge. I learned with trial and error and much googling.

That error is not critical. The script will still work. If you insist on getting rid of the error, you can add ProjectComponent component = event.projectComponent Then in the findByComponentName, use component.name instead.

You will have no errors if you select the correct events in the listener

That should work, that was the whole point to changing def dest_proj = "TS" to def dest_proj = ["TS"] This question about updating a component name sure turned into something ... Here is a completely rewritten script that will allow you to sync components from a project (identified in the script listener configuration)…

Sorry, never tried deleting components programmatically before. You can try to add this to your listener if (event instanceof ProjectComponentDeletedEvent) { event = event as ProjectComponentDeletedEvent dest_prj.each { String deskProjectKey -> def project = projectManager.getProjectObjByKey(deskProjectKey) def…

Can you share some more details? Are there any errors in the script editor? Do you see errors in the execution log (open the workflow/transition after executing the transition to view execution logs). Maybe we can add some additional logging to help with identifying where it's failing: log.info "'AM Application' is…

I was clearly under-caffeinated yesterday ... there was another typo: coponents vs components cfValues["AM Application"].value != "JIRA" || issue.components

I've never user ProjectComponentService. But it looks like it can only be used to remove a component from issues. Are you trying to delete a project component from a project?

Behaviours comes with a "getRequestTypeName()" method that you can call. Armed with that, you can convert that script to something quite simple: Map validComponentNamesByRequestType = [ "Sales": ["Purchase", "Return"], ] if (!requestTypeName) { //no requestTypeName is available at this time (also happens when creating…

Just cast your map to the type expected by the interface @Override List<Map> getArguments() { [ ["project": "Project Key", "optional": false], ["role": "Role X", "optional": false] ] as List<Map> }

If you are executing this in a post function, it's quite possible that the issue object that exists in memory during the transition overwrites your changes. Normally, within a post function, I use the built-in issue object. As long as the sequence has this post function before the "update change history for an issue and…

Remove those 2 lines, they are duplicates of line 32 and 33.

Sorry... I was sloppy. It should be "cfValues", the built-in variable that scriptrunner offers that includes all the custom field values in an easily accessible map. cfValues["AM Application"].value != "JIRA" || issue.coponents

Not all static type-checking errors are necessarily bad. When event can be many different type, the editor doesn't know what type to consider. You can cast "event" accordingly: def component = (event as ProjectComponentUpdatedEvent).projectComponent def oldComponentName = (event as…

Try like this: def dest_prj = ["TS"] def source_prj = 'TH' import com.atlassian.jira.bc.project.component.MutableProjectComponent import com.atlassian.jira.component.ComponentAccessor import com.atlassian.jira.event.bc.project.component.ProjectComponentCreatedEvent import…

It is possible to achieve this with either a Behaviour or a validator. Behaviour scripts are capable of knowing which part of the workflow you are in. This is a good choice if you want to prevent users from clearing the component using the edit screen after it's deemed required. Of course, a validator will work inherently…

Oh ... where do you have your script? Did you put it in the description server-side script? If so, then that's would be the issue. Default description scripts have to be put in the initializer. Otherwise, each time you edit the description, when you leave the field, the script executes and resets the field.

Can you show me the full configuration screen for your behaviour? Do you have other behaviours that map to the same project/issuetype (or all projects/all issuetypes)

This will only work without the even listener context. You need to have access to the "oldComponent" from the source project to be able to identify which component in the destination project needs to be renamed.

If you were returning a single repository, then ?fields=full_name would work to only show that field. Frankly, I figured it out with trial and error and it's when i tried to retrieve a single repository that I saw that the ?field worked. All prior attempts were causing empty objects to be returned.

You have to tell the api where the "full_name" or links field is. In this case, it's inside "values" try with ?fields=values.full_name

Please review the second script I included in my response, it should suit your need.

Let me see if I understand ... you want to update the name in the source project and have the component matching the old name to be updated to the new name in all the destination projects? Before I understood that, I reviewed your script and thought it could be made a little easier to read: def destProjectKeys = ["TS"] def…

Try this version... There was an error on line 55 of your screenshot. import com.atlassian.jira.component.ComponentAccessor import com.atlassian.jira.issue.Issue import com.atlassian.jira.issue.fields.CustomField import com.atlassian.jira.user.ApplicationUser import…

WIthout actually having tested anything, why don't you just leverage the "currentProject" object you're already getting via the ProjectActionSupport (I've never used that). I would do this first so you don't bother checking permissions if the project isn't correct. You could do it like this (a bit of future-proofing if you…

Ah... all your code example about Future date appeared to be on the Detected Date. Try this way: import com.onresolve.jira.groovy.user.FieldBehaviours import com.atlassian.jira.component.ComponentAccessor import com.atlassian.jira.user.util.UserUtil import java.util.Date.* def startDateField = getFieldByName("Defect…

This looks good. What's the problem?

The same script has to be placed in both the Defect Detected Date and Defect Closed Date server-side script. Beyond that, I'll need to see more concrete examples with screenshots etc.

Oops, I must have been distracted when I wrote this line: def issue=ComponentAccessor.issueManager.getCustomFieldObject("YOURKEY-123") It should be def issue=ComponentAccessor.issueManager.getIssueObject("YOURKEY-123")

Try it like this: import com.onresolve.jira.groovy.user.FieldBehaviours import com.atlassian.jira.component.ComponentAccessor import com.atlassian.jira.user.util.UserUtil import java.util.Date.* def startDateField = getFieldByName("Defect Detected Date") def startDateValue = startDateField.getValue() as Date def…