Page 1 of 1

last_updated field behavior

Posted: 29 Jan 2010, 11:00
by ddenjean
Hello,

I have to implement reports on Mantis stats.
We have seen that the field mantis_bug_table.last_updated is not updated for all actions...
For example i have in the mantis_bug_history_table some records concerning bugs older than last updated field. (mantis_bug_history_table.date_modified > mantis_bug_table.last_updated)
These cases concern custom fields update or history records of type 12 or 18. Concerning these types if you have a link or explanation regarding theirs values it would be useful for my understanding.

So when last_updated field is update? For what actions if this is not for all ?

Thank you for your help to improve my understanding of Mantis.

Regards

David Denjean
Extelia
France

Re: last_updated field behavior

Posted: 29 Jan 2010, 14:33
by atrol
At first sight, it makes sense, that 12 and 18 are not treated as an update action (12 is starting monitoring, 18 is adding of bug relationship)
I assume you are using MantisBT version 1.1.x ?

snippet of constant_inc.php

Code: Select all

# history constants
define( 'NORMAL_TYPE', 0 );
define( 'NEW_BUG', 1 );
define( 'BUGNOTE_ADDED', 2 );
define( 'BUGNOTE_UPDATED', 3 );
define( 'BUGNOTE_DELETED', 4 );
define( 'DESCRIPTION_UPDATED', 6 );
define( 'ADDITIONAL_INFO_UPDATED', 7 );
define( 'STEP_TO_REPRODUCE_UPDATED', 8 );
define( 'FILE_ADDED', 9 );
define( 'FILE_DELETED', 10 );
define( 'BUGNOTE_STATE_CHANGED', 11 );
define( 'BUG_MONITOR', 12 );
define( 'BUG_UNMONITOR', 13 );
define( 'BUG_DELETED', 14 );
define( 'BUG_ADD_SPONSORSHIP', 15 );
define( 'BUG_UPDATE_SPONSORSHIP', 16 );
define( 'BUG_DELETE_SPONSORSHIP', 17 );
define( 'BUG_ADD_RELATIONSHIP', 18 );
define( 'BUG_DEL_RELATIONSHIP', 19 );
define( 'BUG_CLONED_TO', 20 );
define( 'BUG_CREATED_FROM', 21 );
define( 'CHECKIN', 22 );
define( 'BUG_REPLACE_RELATIONSHIP', 23 );
define( 'BUG_PAID_SPONSORSHIP', 24 );
define( 'TAG_ATTACHED', 25 );
define( 'TAG_DETACHED', 26 );
define( 'TAG_RENAMED', 27 );
define( 'PLUGIN_HISTORY', 100 );
But the behaviour changed in 1.2 where for example montoring is now changing the last updated field.
I don't know whether this was a bug or a feature in 1.1
Maybe this is a more philosophical discussion: If someone decides to monitor a bug, is this an update of the bug?
Seems that developers decided to see this as an update.

What does this mean for you?
Your truth can only be found in your source code:
You have to look at least at bug_api.php, especially at the calls of bug_update_date
Furthermore you will have to change your reports when upgrading your MantisBT installation to 1.2

If you find any actions where you think that the last update time should be updated but is not, please enter an issue in MantisBT's own tracker

Re: last_updated field behavior

Posted: 19 May 2010, 10:32
by gujili
Me too, Iam also in the same confusion between last modified date in the issue history and the modified date displayed in the 'notes' or comments section.
I need to know when was the last time the final comment or Note was added to an issue and I want to find the difference in days between 'Date Submitted' and 'Notes changed date ' only. For example: if an issue was submitted on 01-Jan and the last note was added on 15-Jan, then the difference of days is 14 days. Assume if the status is changed on 17-Jan, then the difference is 16 days, but I want my report to display only the 'notes change' i.e. 14 days only.

Any help on this? Thanks a lot.

Re: last_updated field behavior

Posted: 20 May 2010, 08:19
by atrol
Have a look at the code snippet with constants that I attached in my previous post.
Select all records of mantis_bug_history_table where type is what you are interested in.

For example something like

Code: Select all

SELECT date_modified FROM mantis_bug_history_table where  bug_id = <yourBugId> AND type IN (2,3,4) ORDER BY date_modified DESC LIMIT 1;

Re: last_updated field behavior

Posted: 27 May 2010, 08:48
by gujili
Thanks atrol. I understand. Its working.