Hello Venkatesh Pokala
You will have to build some more advanced logic into how the status of the source issue advances.
One approach could be to track the remote status of each connected issue in one or more custom fields
For instance
In the incoming sync processor connection F6755_to_RAX20, set the remote status RAX20 as follows
issue.customFields."Remote Status RAX20".value = replica.status.name
and do the same in the connection F6755_to_LAX20
issue.customFields."Remote Status LAX20".value = replica.status.name
In both incoming processors advance then the source status based on the content of the remote status fields
if (issue.project.key == "F6755") {
def remoteStatusRAX20 = issue.customField."Remote Status RAX20'.value
def remoteStatusLAX20 = issue.customField."Remote Status LAX20'.value
if (remoteStatusRAX20 == "Rejected" && remoteStatusLAX20 == "Rejected") {
issue.status = "Rejected"
}
This is untested code - but you can get the idea
Hi Francis,
You mean do I need to use the "advanced" connection? instead of single?
Thanks,
Venkatesh.
I meant that you need to develop a more advanced synchronization, using an approach as depicted above.
If interested - we can bring you in contact with one of our exalate partners that can provide the necessary services to implement this use case.
Let me know
I definitely let you know if we required partner support. I tried your suggestions but unfortunately not able to get the remote status
Cannot get property 'Remote Status RAX20' on null object.
Can you please help us to unblock this issue?. Thank you so much for your help.
Thanks,
Venkatesh.
Keep in mind that working with a partner will get you much quicker the result you need. The alternative is that you need to go through a learning curve, and understand what is happening before you can get to a result.
Regarding
> Cannot get property 'Remote Status RAX20' on null object.
This is not sufficient context .
I cannot help with the information you provided.
Hi Team,
We created two local (single project) connections
I. SOURCE_to_DEST1
II. SOURCE_to_DEST2
Below are the user requirements and findings: Please help us to configure this way.
1. In “Exalate” field, can the destination projects be multiply selectable? We will have many projects.
2. I created SOURCE-1 (master case) to sync both DEST1-1 and DEST2-1.
(a) When I OPEN DEST1-1, SOURCE-1 is OPEN. (good)
(b) When I REJECT DEST1-1, SOURCE-1 is REJECTED. DEST2-1 is still OPEN state. à It’s not expected. Our target is when all connected JIRA cases are CLOSED or REJECTED, then the master case is closed.
3. I created the SOURCE-2 (master case) to sync both DEST1-2 and DEST2-2.
(a) When I OPEN DEST2-2, SOURCE-2 is open and DEST1-2 keep NEW. (good)
(b) When I Fix DEST2-2, SOURCE-2 is FIXED. DEST1-2 status keep the same (ok)
(c) When I Close DEST2-2, SOURCE-2 is CLOSED. DEST1-2 status keep the same à It’s not expected. Our target is when all connected JIRA cases are CLOSED or REJECTED, then the master case is closed.
4. Can the sync cases showed in the master case? Below is the example, show the case status after JIRA case (red font).
Thanks,
Venkatesh.