From: <pa...@qu...> - 2008-07-06 20:57:45
|
if a user monitors/unmonitors an issue, the issue itself isn't being updated so i'm not sure this should touch the bug itself. If someone had a policy of ensuring customers were updated on an issue at least once per week, you would achieve this by looking at the last_updated date - I wouldn't therefore call someone 'unmonitor'ing an issue as a progress update... Am I way off, or should this be reversed/configuration option? Paul > Revision: 5393 > http://mantisbt.svn.sourceforge.net/mantisbt/?rev=5393&view=rev > Author: vboctor > Date: 2008-07-05 15:28:47 -0700 (Sat, 05 Jul 2008) > > Log Message: > ----------- > Fixed #9348: Monitoring/unmonitoring an issue should update it's last > modified date. > > Modified Paths: > -------------- > trunk/mantisbt/core/bug_api.php > > Modified: trunk/mantisbt/core/bug_api.php > =================================================================== > --- trunk/mantisbt/core/bug_api.php 2008-07-05 22:15:58 UTC (rev 5392) > +++ trunk/mantisbt/core/bug_api.php 2008-07-05 22:28:47 UTC (rev 5393) > @@ -1685,6 +1685,9 @@ > # log new monitoring action > history_log_event_special( $c_bug_id, BUG_MONITOR, $c_user_id ); > > + # updated the last_updated date > + bug_update_date( $p_bug_id ); > + > return true; > } > > @@ -1720,6 +1723,9 @@ > # log new un-monitor action > history_log_event_special( $c_bug_id, BUG_UNMONITOR, $c_user_id ); > > + # updated the last_updated date > + bug_update_date( $p_bug_id ); > + > return true; > } > > > > This was sent by the SourceForge.net collaborative development platform, > the world's largest Open Source development site. > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > mantisbt-cvs mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-cvs > > |
From: Gianluca S. <gi...@gm...> - 2008-07-07 07:02:10
|
On Sun, Jul 6, 2008 at 10:57 PM, <pa...@qu...> wrote: > if a user monitors/unmonitors an issue, the issue itself isn't being > updated so i'm not sure this should touch the bug itself. > > If someone had a policy of ensuring customers were updated on an issue at > least once per week, you would achieve this by looking at the last_updated > date - I wouldn't therefore call someone 'unmonitor'ing an issue as a > progress update... > > Am I way off, or should this be reversed/configuration option? > I think I agree with you here. We probably need a clear list of what constitutes an "update" for a bug and what does not. FTIW, I think a bug is updated when actions that requires the update_bug_threshold are performed. -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna |
From: Victor B. <vb...@gm...> - 2008-07-07 09:06:05
|
Hi Paul, Gianluca, I had a quick look at the code and following is the current behavior before my changes: 1. Update issue header information (which required update threshold, yes) 2. Sticky (no) 3. Monitor (monitor/unmonitor: no) 4. Tag (attach, detach: no) 5. Relationship (add: yes, delete: no) 6. Notes (add: yes, delete: no) 7. Attachments (add: yes, remove: no) 8. Voting (once it's completed) 9. Move issue (no) 10. Clone Issue (if relationship added, then follow relationship model, otherwise no) 11. Assign/Change Status (yes) 12. Sponsorship (add: yes, delete: yes) Some general thoughts: 1. I don't agree about only updating the last modified time when the update issue threshold is required, since this would exclude notes which are the primary means of providing customers with update. 2. I generally think it is a good idea to have consistency between add / remove operations. 3. I don't mind having the time stamp update behavior for each action (e.g. tagging, relationships - not add/remove) controlled by configuration options. However, we still need to figure out the defaults. 4. For tagging / monitoring, I'm ok with having the default = NO, but for the official bug tracker, I would like it to be YES. The reason is that I want any activity done a user on an old issue to cause it to go to the top so that we can see it. This may be less of an issue once the voting feature is added and it updates the timestamps as customers vote for the features. 5. For companies that want to find issues that are not updated within the last week, I think they should determine the effective last updated time based on the last note by a staff member. For example, a custom asking about the status of the an issue via an issue note is not considered an update. In my opinion, for such companies, any change to the header information should also be accompanied by a note to the customer. However, these customers can also tune the configuration options that determines what updates the timestamps and what doesn't. 6. Sometimes we call bug_update_date() in the action pages and sometimes in the APIs. I think we should move all such updates to the APIs. If there are scenarios where we don't want to trigger the update, then we should add a parameter to the API. This will derive consistency, so that if an action is done via the web interface / SOAP API, the behavior will be similar. Now that we have the details above, lets see the feedback. On Mon, Jul 7, 2008 at 12:01 AM, Gianluca Sforna <gi...@gm...> wrote: > On Sun, Jul 6, 2008 at 10:57 PM, <pa...@qu...> wrote: >> if a user monitors/unmonitors an issue, the issue itself isn't being >> updated so i'm not sure this should touch the bug itself. >> >> If someone had a policy of ensuring customers were updated on an issue at >> least once per week, you would achieve this by looking at the last_updated >> date - I wouldn't therefore call someone 'unmonitor'ing an issue as a >> progress update... >> >> Am I way off, or should this be reversed/configuration option? >> > > I think I agree with you here. We probably need a clear list of what > constitutes an "update" for a bug and what does not. > > FTIW, I think a bug is updated when actions that requires the > update_bug_threshold are performed. > > > > -- > Gianluca Sforna > > http://morefedora.blogspot.com > http://www.linkedin.com/in/gianlucasforna > |