| Summary: | migrated transitions are not correctly recognized on Bugzilla 4.0 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Steffen Pingel <steffen.pingel> | ||||||||||||
| Component: | Mylyn | Assignee: | Frank Becker <eclipse> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Frank Becker <eclipse> | ||||||||||||
| Severity: | major | ||||||||||||||
| Priority: | P3 | CC: | tommacco | ||||||||||||
| Version: | unspecified | ||||||||||||||
| Target Milestone: | 3.6.2 | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Linux | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Bug Depends on: | |||||||||||||||
| Bug Blocks: | 337245 | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Steffen Pingel
Created attachment 201656 [details]
actions section
Why don't we use the status values from the configuration to populate the workflow transitions? We also need to fix the labels: Unconfirm (change status to UNCONFIRMED) Confirm (change status to CONFIRMED) Accept (change status to IN_PROGRESS) Verify Steffen here in my patch http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.git/commit/?id=02f7880167a52d79a1ba29cc75a948591c53bb9a can you please verify becaus I can not test this :-( I did not know my password for https://bugs.eclipse.org/bugstest an must wait until 8/28 My MacMiniServer is down so I can not steup an local test environment Created attachment 201853 [details]
mylyn/context/zip
Steffen, I found an problem so here is the fix for the previous patch! Created attachment 201946 [details]
mylyn/context/zip
Thanks a lot for the fixes! I have applied both commits to the e_3_7_m_3_6_x branch. I made another commit to update the labels as proposed in comment #3: * Unconfirm (change status to UNCONFIRMED) * Confirm (change status to CONFIRMED) * Start (change status to IN_PROGRESS) * Verify as ... Everything seems to work with as expected with Eclipse.org bugstest Bugzilla now. While testing with a local stock Bugzilla 4 (not migrated) I noticed some inconsistencies: * When a bug is "Verified" I get an error when trying to resolve it (the web does not show this transition). * I never get the option to set a bug to "Unconfirmed". The repository configuration looks good but the BugzillaAttribute.EVERCONFIRMED flag is always null for me and hence the status is not added. Could you take a look at that? It wasn't quite clear to me how the EVERCONFIRMED flag works. (In reply to comment #8) > Thanks a lot for the fixes! I have applied both commits to the e_3_7_m_3_6_x > branch. I made another commit to update the labels as proposed in comment #3: > > * Unconfirm (change status to UNCONFIRMED) > * Confirm (change status to CONFIRMED) > * Start (change status to IN_PROGRESS) > * Verify as ... > > Everything seems to work with as expected with Eclipse.org bugstest Bugzilla > now. > > While testing with a local stock Bugzilla 4 (not migrated) I noticed some > inconsistencies: > > * When a bug is "Verified" I get an error when trying to resolve it (the web > does not show this transition). Can I access this instance? What version did you install? mylyn.eclipse.org/bugs40 and mylyn.eclipse.org/bugshead use the VERIFIED! > * I never get the option to set a bug to "Unconfirmed". The repository > configuration looks good but the > BugzillaAttribute.EVERCONFIRMED flag is always null for me and hence the status > is not added. UNCONFIREMED is set off by default you can turn it on using .../editproducts.cgi?action=edit&product= > > Could you take a look at that? It wasn't quite clear to me how the EVERCONFIRMED > flag works. The EVERCONFIRMED is set to 1 when you have an open status which is not UNCONFIRMED (In reply to comment #9) > > * When a bug is "Verified" I get an error when trying to resolve it (the web > > does not show this transition). > > Can I access this instance? I tried again with http://mylyn.org/bugs40/show_bug.cgi?id=79 and it worked. In my local Bugzilla configuration the transition is actually allowed so I am not sure why it's not working, but let't not worry about it. > > * I never get the option to set a bug to "Unconfirmed". The repository > > configuration looks good but the > > BugzillaAttribute.EVERCONFIRMED flag is always null for me and hence the > status > > is not added. > UNCONFIREMED is set off by default you can turn it on using > .../editproducts.cgi?action=edit&product= The Bugzilla instance is configured correctly and the flag is present in the repository configuration. Still, this check in RepositoryConfiguration never evaluates to true: if (everConfirmed == null && unconfirmedAllowed)... I looked for references to BugzillaAttribute.EVERCONFIRMED but I couldn't find a place where this attribute would ever get set? (In reply to comment #10) > (In reply to comment #9) > > > * When a bug is "Verified" I get an error when trying to resolve it (the web > > > does not show this transition). > > > > Can I access this instance? > > I tried again with http://mylyn.org/bugs40/show_bug.cgi?id=79 and it worked. In > my local Bugzilla configuration the transition is actually allowed so I am not > sure why it's not working, but let't not worry about it. What is the content of the .../editworkflow.cgi did you change something? Maybe bugzilla has changed the default transitions! > > > > * I never get the option to set a bug to "Unconfirmed". The repository > > > configuration looks good but the > > > BugzillaAttribute.EVERCONFIRMED flag is always null for me and hence the > > status > > > is not added. > > UNCONFIREMED is set off by default you can turn it on using > > .../editproducts.cgi?action=edit&product= > > The Bugzilla instance is configured correctly and the flag is present in the > repository configuration. Still, this check in RepositoryConfiguration never > evaluates to true: > > if (everConfirmed == null && unconfirmedAllowed)... > > I looked for references to BugzillaAttribute.EVERCONFIRMED but I couldn't find a > place where this attribute would ever get set? SaxMulitBugReportContentHandler.endElement the default from the switch is the place where the attribute is set. .../show_bug.cgi?id=79&ctype=xml includes the line <everconfirmed>1</everconfirmed> Created attachment 202275 [details]
mylyn/context/zip
Thanks for the explanation. I enabled the unconfirmed status for the Manual Testing product of http://mylyn.org/bugs40/ but still couldn't get the Unconfirmed status to show in the editor. Please take a look at this change and let me know if that fix makes sense: http://review.mylyn.org/#change,10 . (In reply to comment #13) > Thanks for the explanation. I enabled the unconfirmed status for the Manual > Testing product of http://mylyn.org/bugs40/ but still couldn't get the > Unconfirmed status to show in the editor. Please take a look at this change and > let me know if that fix makes sense: http://review.mylyn.org/#change,10 . We must change the group reg expression for group can confirm from .* to something thad does not match for all users and an not permitted user must fill an new bug. (In reply to comment #14) > We must change the group reg expression for group can confirm from .* to > something thad does not match for all users and an not permitted user must fill > an new bug. Please feel free to do that. Please email me if you need credentials to access the server. Steffen, I have commit an patch id=0da1145ea2f5c37d1b5d0c8ac8ab63fa9d6ae270. This was tested with http://mylyn.org/bugshead/show_bug.cgi?id=93 Thanks! If I open http://mylyn.org/bugshead/show_bug.cgi?id=93 in the web (as admin... or tests...) I get an option to set the bug to Unconfirmed but I don't see this in the task editor. Do you know why? Steffen only before 2011-08-30 20:47:36 CEST you can have seen the UNCONFIRMED state After this time it changed to CONFIRMED because the test@mylyn.eclipse.org user set this bug to IN_PROGRESS and the ever confirmed was changed from 0 to 1 (see http://mylyn.org/bugshead/show_activity.cgi?id=93) Can you thy this with an new mylyn.org/bugshead/ bug? I just set it back to unconfirmed: http://mylyn.org/bugshead/show_activity.cgi?id=93 ? Created attachment 202498 [details]
default workflow matrix
Steffen, here my next fix. I hope that we are done here! *** Bug 356409 has been marked as a duplicate of this bug. *** Great. Thanks. I have cherry picked the commits to the e_3_7_m_3_6_x branch. |