#4936 Project upgrade discarded ticket 'resolution' values [ss541]

v1.0.0
closed
nobody
support (446) p3 (267) migration (63) 42cc (432)
General
Dave Brondsema
2015-08-20
2012-09-13
Chris Tsai
No

[forge:site-support:#541]

The SF2 Tickets tool seems to try to combine the functions of the separate 'status' and 'resolution' fields of the old SF1 Trackers into a single 'status' field. There are very good reasons to keep 'resolution' and 'status' separate when tracking bugs and feature requests, and that is how Bugzilla does it too.

I understand that I can use the custom field function to add Resolution to all my ticket tools, with a menu of values. And I discovered that if I enable "Show in search" for that field, then the new field shows in the ticket listing. (Undocumented feature?)

The problem is that when the SF1 tracker data was upgraded to the SF2 tickets tool, all the 'resolution' values were apparently discarded. For record-keeping purposes, this is a big deal, as there is no way to determine how a ticket was resolved except what you can glean from the comments. For example, this old bug report has status=Closed but doesn't say why. From my pre-upgrade XML backup, I can see the resolution was 101=Duplicate.

(While I am complaining about Tracker to Tickets migration, it would have been nice to have a populated "old ID" field, so when my NEWS or ChangeLog says "fixed bug #1234567", I had some way of finding the new ticket for it, other than searching by summary.)

Perhaps we should add each resolution that's used to "Closed Statuses" during migration?

Related

Tickets: #4936

Discussion

  • Chris Tsai - 2012-09-13
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,10 +1,10 @@
 [forge:site-support:#541]

->The SF2 Tickets tool seems to try to combine the functions of the separate 'status' and 'resolution' fields of the old SF1 Trackers into a single 'status' field. There are very good reasons to keep 'resolution' and 'status' separate when tracking bugs and feature requests, and that is how Bugzilla does it too.
+>The SF2 Tickets tool seems to try to combine the functions of the separate 'status' and 'resolution' fields of the old SF1 Trackers into a single 'status' field.  There are very good reasons to keep 'resolution' and 'status' separate when tracking bugs and feature requests, and that is how Bugzilla does it too.

->I understand that I can use the custom field function to add Resolution to all my ticket tools, with a menu of values. And I discovered that if I enable "Show in search" for that field, then the new field shows in the ticket listing. (Undocumented feature?)
+>I understand that I can use the custom field function to add Resolution to all my ticket tools, with a menu of values. And I discovered that if I enable "Show in search" for that field, then the new field shows in the ticket listing. ([Undocumented feature?](https://sourceforge.net/p/forge/documentation/Tracker%20-%20Beta/))

->The problem is that when the SF1 tracker data was upgraded to the SF2 tickets tool, all the 'resolution' values were apparently discarded. For record-keeping purposes, this is a big deal, as there is no way to determine how a ticket was resolved except what you can glean from the comments. For example, this old bug report has status=Closed but doesn't say why. From my pre-upgrade XML backup, I can see the resolution was 101=Duplicate.
+>The problem is that when the SF1 tracker data was upgraded to the SF2 tickets tool, all the 'resolution' values were apparently discarded. For record-keeping purposes, this is a big deal, as there is no way to determine how a ticket was resolved except what you can glean from the comments. For example, [this old bug report](https://sourceforge.net/p/phplot/bugs/19/) has status=Closed but doesn't say why. From my pre-upgrade XML backup, I can see the resolution was 101=Duplicate.

 >(While I am complaining about Tracker to Tickets migration, it would have been nice to have a populated "old ID" field, so when my NEWS or ChangeLog says "fixed bug #1234567", I had some way of finding the new ticket for it, other than searching by summary.)
     

    • Prefabbricati

      Prefabbricati - 2017-11-29

      The first link of sourceforge (Undocumented feature) not working.

       

  • Dave Brondsema

    Dave Brondsema - 2012-10-02
    • milestone: limbo --> forge-oct-19
     

  • Dave Brondsema

    Dave Brondsema - 2012-10-02

    Yeah, I think if Resolution is not None, we should incorporate it into the status. E.g. "Closed-Invalid" or "Pending-Remind"

     

  • Dave Brondsema

    Dave Brondsema - 2012-10-05
    • size: --> 1
     

  • Dave Brondsema

    Dave Brondsema - 2012-10-24
    • labels: support, p3, migration --> support, p3, migration, 42cc
     

  • Igor Bondarenko - 2012-10-25

    Created #194: [#4936] Keep ticket 'resolution' values during project update (1cp)

     

    Related

    Tickets: #4936

  • Igor Bondarenko - 2012-10-25
    • status: open --> in-progress
     

  • Dave Brondsema

    Dave Brondsema - 2012-11-02
    • Milestone: forge-nov-16 --> forge-backlog
     

  • Igor Bondarenko - 2012-11-05
    • status: in-progress --> code-review
     

  • Igor Bondarenko - 2012-11-05

    Closed #194. Branch je/42cc_4936 in forge-classic repo.

    Also this needs changes in allura (branch 42cc_4936 in allura repo)

     

  • Dave Brondsema

    Dave Brondsema - 2012-11-05

    The code provided is pretty good, but there are a few issues:

    • The new combined statuses show up on a ticket, but if I go to edit that ticket, only one of my tests (open-remind) show in the Status drop-down. I thought that's what the append_open_status_name/append_closed_status_name was for, but it doesn't seem like its working. Specifically, closed-fixed and pending-accepted don't show up. Perhaps this is because those names overlap with statuses already in the lists (pending, accepted, closed, etc). Ideally we would eliminate those default statuses if the project migration sets up new statuses with very similar names.
    • the default saved searches for "open" and "closed" tickets should be set to include all the new values, so that they still work.
     

  • Dave Brondsema

    Dave Brondsema - 2012-11-05
    • status: code-review --> open
    • qa: Dave Brondsema
     

  • Igor Bondarenko - 2012-11-06

    I thought that's what the append_open_status_name/append_closed_status_name was for, but it doesn't seem like its working

    Strange.. we'll check that again.

    Ideally we would eliminate those default statuses if the project migration sets up new statuses with very similar names.

    So, we should remove default status if it appears with any of the resolutions? E.g. if we have open-remind should we delete open?

     

  • Igor Bondarenko - 2012-11-06
    • status: open --> in-progress
     

  • Igor Bondarenko - 2012-11-06

    Created #204 for that: [#4936] 'Status-Resolution' improvements (1cp)

     

    Related

    Tickets: #4936

  • Dave Brondsema

    Dave Brondsema - 2012-11-06

    Yes, I think that approach would work well. It doesn't have to be perfect since we don't have a perfect match between classic statuses and the default new statuses, but I think that'll be close enough.

     

  • Igor Bondarenko - 2012-11-12

    Closed #204. Branch je/42cc_4936a

    Code was a little bit rewritten, thus we don't need changes in allura.

     

  • Igor Bondarenko - 2012-11-12
    • status: in-progress --> code-review
     

  • Dave Brondsema

    Dave Brondsema - 2012-11-14
    • size: 1 --> 0
     

  • Dave Brondsema

    Dave Brondsema - 2012-11-20

    tests pass; no allura changes needed

     

  • Dave Brondsema

    Dave Brondsema - 2012-11-20
    • status: code-review --> closed
    • milestone: forge-backlog --> forge-nov-30
     

Log in to post a comment.