Bug 619547

Hi guys,

I am wondering if this functionality is required? As I understand the idea of the JIRA to Bugzilla migration is to move all bugs from JIRA to Bugzilla. Based on this, there would be no need to create any sort of integration between the two (other than for the one way migration)

Please confirm if I can mark this bug was CLOSED/WONTFIX.

  -- simon

Understand that only product / platform bugs will be moved to bugzilla. Work on the upstream projects, which is the majority of engineering work, continues in the project JIRA. 

Presently we shadow upstream project JIRAs in the platform JIRA, and link the two so that the platform JIRA can be updated as the project JIRA is resolved.

Once we move product / platform JIRAs to bugzilla, we will continue to create shadow bugs in the product for the project engineering. We need to link those product defects with their corresponding project engineer trackers. Product defects will be in bugzilla, project engineering trackers will be in JIRA.

Conclusion: Definitely necessary. Do not close without implementing the functionality.

Does this make sense?

Hi all,

Can someone please give specific details as to what is required, preferably with an example or two? Is this simply a case of creating a link with the external tracker functionality, or are you wanting Bugzilla to automatically update the issue in JBoss's JIRA?

  -- simon

There should be a directional link between the two issue systems - just like it is possible in jboss.org jira today.

The usecase is that majority of the product issues will be related to .org issues and that there will be cross cutting issues.

Examples of this in practice:
https://issues.jboss.org/browse/JBIDE-6708 - crosslinked to https://issues.jboss.org/browse/HORNETQ-554

https://issues.jboss.org/browse/JBIDE-6984 - crosslinked to multiple issues, some from project others from product.

All of these links was created by just one action (Add link) - no need to go on both sides.

Is this what bug 584944 fixes? If not, can someone please give me an example of what bug on bz-web2-test.devel.redhat.com is missing a link to an existing JIRA bug?

Or if I have completely missed the mark (based on comment #3 and comment #5), please let me know.

Marking as QA as I believe bug 584944 fixes this issue to. Please mark as VERIFIED if you agree, or ASSIGNED (with a details comment) if work is required.

  -- simon

Simon, please see https://bz-web2-test.devel.redhat.com/show_bug.cgi?id=BRMS-535

The specific JIRA (BRMS-535) is in the "External trackers" and that is fine. However, its "Status" field and the others are left blank. I believe that this request was to synchronize these fields with JIRA and back.

To make things absolutely clear, I think that the request is to have some agent in place to update these "External trackers" fields regularly as the respective issue in the external tracker changes.

+1 - bugzilla will have to reflect the current state of the externally linked bugs - otherwise, it won't be obvious to bugzilla users if a linked bug has changed.

Lukáš / Len: Can you provide more information about what you are requesting, with an example if possible? In what situation would the list of external trackers change?

From what I think you are requesting, this could potentially be a major change.

  -- simon

Let's try a use-case:

1) I add a JIRA issue to the External Trackers section here in this bug.
2) Bugzilla reads the resolution to the bug and fills it in the bug. Let's say it's "Coding in Progress".
3) Some time passes and someone resolves the JIRA in question. (Changing the resolution to "Resolved".)
4) Bugzilla notices the change and updates the "External Trackers" section in this bug with the proper resolution.

At today's bz meeting, the team acknowledged that the feature per this bz 619547 as requested has not been fully implemented.  We would like some ws running (or maybe a nightly batch process) to update the bz.  For example, bugzilla notices a Jira resolution change and the change and updates the bz "External Trackers" section in this bug with the proper resolution from Jira.  The team agreed to go live as is and evaluate and learn and then fully implement this needed functionality in a subsequent bz update.

Here is an update on the issue. The link between bugzilla and jira is working on my test server. Vlastimil is working on writing the JIRA plugin that will allow JIRA to update Bugzilla. I'm hoping to release the code onto bz-wen2-test.devel.redhat.com by the end of the week.

One limitation has been discovered however. If the JIRA issue is Closed, comments and status updates in Bugzilla will not be sent to JIRA. This is because JIRA does not allow new comments to be made on closed issues.

The code is based on send-and-forget RPC calls. Bugzilla will make one attempt to contact JIRA. If it fails, the Bugzilla team are notified, but no resend is attempted. Given that both systems have high availability, I do not expect this to be a problem. If it does become one, we can readdress this issue.

Vlastimil has written an excellent article in docspace on the link between the systems. Well worth a read if you want the technical details.

https://docspace.corp.redhat.com/docs/DOC-68417

  -- simon

I tried to comment on BRMS-535. The comment was not porpagated to Jira albeit the issue in Jira is resolved, not closed

Created attachment 505995 [details]
Copy of BRMS-535 from the staging JIRA server

The link seems to be working for me. Have a look at the attached screen grab which shows your comment as it appears in JIRA.

  -- simon

Just a note that comments made from bz-web2-test.devel.redhat.com connects to the staging Jira server. (https://issues-stg.jboss.org/). Therefore you can freely make comments on the two systems without it going on the live servers.

  -- simon

Simon - this was the first that I had heard of the staging JIRA server.

Who controls access to this server? How can I get a login?

Agreed, bug.  Duplicated comments does not sound like a desired behaviour.  Max,  Please work with Simon to clarify both the desired and undesired behaviour given the feature developed thus far.  My hope/goal is that we can refine the work/code that Simon has written, arrive at an acceptable and working solution, and only iterate one more time on this required feature.  Once you have entered the bugs you see and the required desired behavior, then please put this ON_Dev to Simon.

(In reply to comment #33)
> Simon - this was the first that I had heard of the staging JIRA server.
> Who controls access to this server? How can I get a login?

The jboss community RT queue seems to be the correct place to request an account on the server.

  -- simon

(In reply to comment #35)
> (In reply to comment #33)
> > Simon - this was the first that I had heard of the staging JIRA server.
> > Who controls access to this server? How can I get a login?
> 
> The jboss community RT queue seems to be the correct place to request an
> account on the server.
> 
>   -- simon

as far as I'm aware all useraccounts are duplicated on the staging server so if you have access to jira.jboss.org you should also have access to the staging jira.

Testing failed during today's bz-->Jira meeting/testing session. 

Steps to reproduce the failure:

Logged into https://issues-stg.jboss.org/secure/Dashboard.jspa using rick_wagner account.  Located a Drools bug:  JBRULES-2909 that we intented to link to BRMS bz 728416 via the "external trackers."  

I choose "JBoss Issue Tracker" and entered JBRULES-2909 into the bug id field, then hit submit.


Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, sysadmin-engops and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Sorry about that. I had the incorrect URL configured in the external tracker settings.

  -- simon

Seeing this failure today - while jointly editing a bz and JIRA:

https://issues-stg.jboss.org/browse/JBRULES-2898
https://bz-web2-test.devel.redhat.com/show_bug.cgi?id=717986

===========================


Mid-air collision detected!

Someone else has made changes to bug 717986 at the same time you were trying to. The changes made were:

No changes have been made to this bug yet.

Added the comment(s):

    Comment 16 Len DiMaggio 2011-07-07 15:07:02 EDT

    Mike say something!

    	

Your comment was:

    Mike say something!
      

You have the following choices:

    *
      This will cause all of the above changes to be overwritten, except for the added comment(s).
    *
    * Throw away my changes, and revisit bug 717986

Midair collisions happen when two people change a bug at the same time (i.e. from the same starting page). This is a feature and not a bug. It is to ensure that two people don't do something opposite at the same time that could cause problems.

Marking as ON_QA

Well, "Midair collisions" might be a "feature", however, it's quite undesirable.  

I hit this problem multiple times while trying to test this feature, and the end result of my testing is that the feature does not do what I would expect...bi-directional updates are lost.  This happened while I tested on my own with one Firefox instance, two FF tabs and test bz in one FF tab and test Jira in the other FF tab.  In this case, as one tester, I could only update either bz or jira at one time, and yet I hit the Midair collision.

Later, Len and I tried with Len in bz and Mike in Jira...both updating the bugs with comments and statuses.  Under both the single user scenario and the multiple user scenario, we hit midair collisions and lost our status/comment updates?

How do you purpose we test this feature and get the expected result that comments and statuses are passed back and fourth and "highly" successful?

Simon, how did you test this feature?  Did you encounter midair collisions?

Thanks.

I think that in a purely Bugzilla environment, the collisions happen when 2 users try to edit the same bz. The workaround for this is that the user seeing the collision has to revisit and add his change a 2nd time.

Are we saying that users will have to expect to have to do the same when they link a JIRA<->Bugzilla? So that they will have to re-execute the linking whenever they see this collision?

But....

If user #1 is editing a bz (e.g., by adding a comment)

And user #2 is at the same time making any other edit to the same bz

And the bz is linked to a JIRA

Will the JIRA fail to be updated when user #2 encounters a collision?

(In reply to comment #44)
> I think that in a purely Bugzilla environment, the collisions happen when 2
> users try to edit the same bz. The workaround for this is that the user seeing
> the collision has to revisit and add his change a 2nd time.

On the MAC (mid air collision) screen, there are three options:
 * Throw away the other persons changes
 * Only submit your comment, and discard other changes
 * Make no changes and view the bug.

The MAC screen also informs you of the other persons changes, so you can access the best course of action. Generally if _your_ only change is to make a comment, then the second option is best.
 
> Are we saying that users will have to expect to have to do the same when they
> link a JIRA<->Bugzilla? So that they will have to re-execute the linking
> whenever they see this collision?

If when linking a bugzilla bug to a JIRA issue for the first time the user gets a MAC, they will need to decide which of the above three options is the best course of action. This is necessary because such an event will occur when two humans are editing the bug at the same time.
 
> But....
> If user #1 is editing a bz (e.g., by adding a comment)
> And user #2 is at the same time making any other edit to the same bz
> And the bz is linked to a JIRA
> Will the JIRA fail to be updated when user #2 encounters a collision?

JIRA will be updated when a comment is made in Bugzilla. So it would depend on which of the above three MAC actions user #2 took. If user #2 eventually made a comment in Bugzilla, then it would be copied to JIRA.

  -- simon

Mike asked me to write down all the usecases for this; here are the ones I can think of - let me know if some fall outside the possible scope.

Some base/general statements for linked and mentioned jiras/bugzillas:

There can be multiple links to multiple bugzillas on each jira and vice versa. i.e. a JBoss Tools issue might related to both a JBDS and EAP issue. Needs to be able to capture that.

If an issue is resolved/closed/rejected etc.(i.e. non-open) the link should be rendered differently than open ones - i.e. with a line going through it.

1) User is working with a jira issue and realizes there is a product issue that this should be tied to - he should be able to add a link to the bugzilla from jira by just typing in the url or just the bug id.

2) User is working with a bugzilla issue and realizes there is a community issue that is related to this issue - he should be able to add a link to the jira from bugzilla by just typing in the url or just the bug id.

During 1 or 2, the url/bug id should be verified that it actually exist so the user knows they have been properly linked. If it does not exist or the system cannot create the link the user should be informed.

Once the link is created there should be a hyperlink visible in both Jira and bugzilla to navigate back and forth. 

It should be possible to "unlink" both ways too.

Note, just to be clear - I do *not* see a usecase of synchronizing comments across the two issue systems - it is not meant for *merging* the two issues, simply linking them.

That reminds me of one aspect we use but isn't that reliant on: each link can be marked as a "type" i.e. "relates to", "depends on", "duplicate off" etc. I believe bugzilla has the same thing.

Simon, please review Max's use cases line by line, and let us know:

-which ones you have tested and "pass" given your current implementation
-which cases should work, but currently fail your testing (have a bug)
-which test cases are completely not supported based on the use case Max has described.

Please note any deviations in how the feature works and what Max is expecting per his use cases.

Thanks,

Mike

After the BZ status changed from Assigned to ON_QA, this JIRA update was expected:

https://issues-stg.jboss.org/browse/JBRULES-2898?focusedCommentId=12585866&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12585866

But, these (duplicated) comments were also generated:

https://issues-stg.jboss.org/browse/JBRULES-2898?focusedCommentId=12585867&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12585867
https://issues-stg.jboss.org/browse/JBRULES-2898?focusedCommentId=12585868&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12585868
https://issues-stg.jboss.org/browse/JBRULES-2898?focusedCommentId=12585869&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12585869
https://issues-stg.jboss.org/browse/JBRULES-2898?focusedCommentId=12585870&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12585870

And...

This JIRA - also linked to bugzilla https://bz-web2-test.devel.redhat.com/show_bug.cgi?id=717986 - is NOT receiving updates: https://issues-stg.jboss.org/browse/JBPAPP-1073

Related bz:

     https://bugzilla.redhat.com/show_bug.cgi?id=720776

User is working with a jira issue and realizes there is a product issue that
this should be tied to - he should be able to add a link to the bugzilla from
jira by just typing in the url or just the bug id.

Feature request

When a JIRA is linked to a bugzilla, a comment should be added to the JIRA that lists the URL of the linked JIRA.

Related bz:

     https://bugzilla.redhat.com/show_bug.cgi?id=720778

User is working with a bugzilla issue and realizes there is a community
issue that is related to this issue - he should be able to add a link to the
jira from bugzilla by just typing in the url or just the bug id.

Feature request - If the JIRA cannot be found, Bugzilla displays "none" - an error should be displayed to the user.

(In reply to comment #51)
> Simon, please review Max's use cases line by line, and let us know:
> 
> -which ones you have tested and "pass" given your current implementation
> -which cases should work, but currently fail your testing (have a bug)
> -which test cases are completely not supported based on the use case Max has
> described.
> 
> Please note any deviations in how the feature works and what Max is expecting
> per his use cases.

(In reply to comment #49)
> There can be multiple links to multiple bugzillas on each jira and vice versa.
> i.e. a JBoss Tools issue might related to both a JBDS and EAP issue. Needs to
> be able to capture that.

This passes. One bugzilla issue can be linked to many different JIRAs and the same JIRA issue can be be linked from many bugzilla bugs.
 
> If an issue is resolved/closed/rejected etc.(i.e. non-open) the link should be
> rendered differently than open ones - i.e. with a line going through it.

Assuming we are talking about the automatic and/or manual links in comments, this is not supported and probably won't be. Bugzilla doesn't have a knowledge of the current status of JIRA issues. Making an RPC call every page load for every bug would not be practical either. Only crossing JIRA issue links for bugs referenced in the external tracker section is a bad idea since non-linked issues might be closed but not crossed out.

> 1) User is working with a jira issue and realizes there is a product issue that
> this should be tied to - he should be able to add a link to the bugzilla from
> jira by just typing in the url or just the bug id.

Not supported. You will need to speak to the JIRA developer about implementing this feature. I can help them on the technical side of things.

> 2) User is working with a bugzilla issue and realizes there is a community
> issue that is related to this issue - he should be able to add a link to the
> jira from bugzilla by just typing in the url or just the bug id.

Supported. You can add a link to JIRA from Bugzilla using the 'External trackers' box just above the comments, by selecting 'JBoss Issue Tracker' as the type, and the issue as the bug id.
 
> During 1 or 2, the url/bug id should be verified that it actually exist so the
> user knows they have been properly linked. If it does not exist or the system
> cannot create the link the user should be informed.

Not supported, but could be done for 2). If you want this, raise it as a separate bugzilla bug blocking both JIRABZ and this bug.

> Once the link is created there should be a hyperlink visible in both Jira and
> bugzilla to navigate back and forth. 

Passed in Bugzilla. Links in the external trackers code on bugzilla makes it a hyperlink (as well as in comments if preceded by the words 'jira' or 'jira issue').

Passed in JIRA. In JIRA comments made from Bugzilla have a hyperlink on comments made that link to the issue.

> It should be possible to "unlink" both ways too.

Not supported. You can unlink from Bugzilla, but not unlink from JIRA. As with 1) above, this is something that the JIRA developers will need to work on. I can help them on the technical side of things.

(In reply to comment #50)
> Note, just to be clear - I do *not* see a usecase of synchronizing comments
> across the two issue systems - it is not meant for *merging* the two issues,
> simply linking them.

Cross commenting was first requested in comment #19.

> That reminds me of one aspect we use but isn't that reliant on: each link can
> be marked as a "type" i.e. "relates to", "depends on", "duplicate off" etc. I
> believe bugzilla has the same thing.

Not supported. Currently external bugs don't have a 'type' of relationship. If you want this, raise it as a separate bugzilla bug blocking both JIRABZ and this bug.

Marking this bug as ON_QA pending any specific requests to change the existing functionality.

  -- simon

This change was put live last year, and I haven't heard any problems (other than other reported bugs) with this feature.

Simon, for what it is worth I actually think this jira integration ended up great!

Still doesn't remove the overhead of having to sync the two systems manually, but at least its possible to track changes across them - and thats *great*. Thank you.