MantisBT - TestLink
View Issue Details
0008731TestLinkRequirement Managementpublic2019-07-31 12:102020-01-20 16:40
resolvedno change required 
1.9.19 (2019 Q1) 
mysql 5.7.27-0ubuntu0.18.04.1
0008731: last change made by undefined
Requirement versions compare page shows that last changes were made by undefined user, but if i look into that change - authorized user is mentioned at the bottom of page just after the date/time stamp.

To make things worse - sometimes this user is mentioned in "Last change" column, sometimes - not.

"Navigator" - "Requirement Specifications" - any requirement - Action - view history.
Errors in browser console:

Uncaught TypeError: element.dispatchEvent is not a function
/lib/requirements/reqView.php?item=requirement&requirement_id=572&:736 Uncaught TypeError: Cannot read property 'load' of undefined
//third_party/DataTables-1.10.4/media/js/jquery.dataTables.js:3287 Uncaught TypeError: Cannot read property 'length' of null
prototype.js:6602 Uncaught TypeError: element.dispatchEvent is not a function
/lib/requirements/reqView.php?item=requirement&requirement_id=114&:1614 Uncaught TypeError: Cannot read property 'load' of undefined
//third_party/DataTables-1.10.4/media/js/jquery.dataTables.js:3287 Uncaught TypeError: Cannot read property 'length' of null
No tags attached.
related to 0008736resolved fman Requirement versions compare page: user reported as 'undefined' 
png undefined-2.png (37,138) 2019-07-31 12:10

jpg testlink_compare.jpg (307,697) 2019-08-01 15:51
jpg reqRevCreateTs.jpg (95,467) 2020-01-19 09:11
Issue History
2019-07-31 12:10vtiNew Issue
2019-07-31 12:10vtiFile Added: undefined-2.png
2019-07-31 21:17fmanNote Added: 0029060
2019-08-01 15:50vtiNote Added: 0029062
2019-08-01 15:51vtiFile Added: testlink_compare.jpg
2019-08-01 15:55fmanNote Added: 0029063
2019-08-02 08:09fmanNote Added: 0029064
2019-08-02 08:09fmanAssigned To => fman
2019-08-02 08:09fmanStatusnew => feedback
2019-08-05 16:38fmanRelationship addedrelated to 0008736
2019-09-04 21:04fmanQA Team - Task Workflow Status => TBD
2019-09-04 21:04fmanStatusfeedback => resolved
2019-09-04 21:04fmanResolutionopen => no change required
2019-09-05 10:28vtiNote Added: 0029131
2020-01-19 09:11hejuFile Added: reqRevCreateTs.jpg
2020-01-19 09:30hejuNote Added: 0029423
2020-01-19 09:32hejuNote Edited: 0029423bug_revision_view_page.php?bugnote_id=29423#r5996
2020-01-19 09:33hejuNote Edited: 0029423bug_revision_view_page.php?bugnote_id=29423#r5997
2020-01-19 09:36hejuNote Edited: 0029423bug_revision_view_page.php?bugnote_id=29423#r5998
2020-01-19 09:41hejuNote Edited: 0029423bug_revision_view_page.php?bugnote_id=29423#r5999
2020-01-19 10:08hejuNote Edited: 0029423bug_revision_view_page.php?bugnote_id=29423#r6000
2020-01-19 22:04fmanNote Added: 0029425
2020-01-19 22:19fmanNote Edited: 0029425bug_revision_view_page.php?bugnote_id=29425#r6004
2020-01-19 22:20fmanNote Edited: 0029425bug_revision_view_page.php?bugnote_id=29425#r6005
2020-01-19 22:43fmanNote Added: 0029426
2020-01-20 14:55vtiNote Added: 0029434
2020-01-20 16:40fmanNote Added: 0029435

2019-07-31 21:17   
please provide very detailed steps to reproduce, that allow recreating a similar scenario.
I need a test case.
2019-08-01 15:50   
1. Open Requirement specification page: https://testlink_base_url/lib/general/frmWorkArea.php?feature=reqSpecMgmt [^]
2. Add some amount of requirements (there are 220 requirement documents in our project)
3. Make changes in requirements and save it (Each requirement's doc has more than 10 revisions and 1 or 2 versions in our project)
4. Open any of requirement's doc
5. Click on settings button
6. Click View History button

Actual result:
All revisions and versions have the same message in "Last change" column

11/07/2018 17:32:21, undefined

Expected result:
There are unique messages (data and the user_name who's made a change) for each revision and version
2019-08-01 15:55   
2019-08-02 08:09   
tested on latest code from github, using just one user.
unable to reproduce
2019-09-05 10:28   
Can't find any additional specific info for reproducing purposes, sorry.
Will keep you informed if anything changes.
2020-01-19 09:30   
(edited on: 2020-01-19 10:08)
Dear fman,

I am observing the same issue. (pls see attached screenshot).

Issue: the revisions all get the same modification_ts as the revision they get created from. The modifier_id is NULL.

Root cause:

in function create_new_revision:
The modification_ts gets only updated if the time stamp is not null:

$nullTS = $this->db->db_null_timestamp();
        $sql .= ",modification_ts = {$nullTS} ";

Otherwise the copy will I think just have the same as the source of the copy.

Problem is now I think:

db_null_timestamp() will return NULL, as on my system $db_type is "mysqli", therefore the case "mysql" in the switch will not execute.

Hopefully my quick analysis is correct and helps a bit.

Apart from that, I would like to ask why the modification_ts shall be set to null date at all?
During the creation of the requirement (version), dates AND the modification dates are set to NOW. Why for the next revision the modification date shall be zero and not to the creation date of the new revision?

In my case I changed the logic a bit in the code: modification_ts and modifier_id are set on creation of new revision to the same values as author_id and creation_ts.
The idea is the same as on e.g. filesystems: on create timestamps for creation, modification and access are the same, when the file is modified later, the dates start to diverge.

Up to now I did not encounter problems with this approach, what do you think?

edit: created a small pull req. to show what I mean: [^]

Note: this may have side effects as the date concept would be a bit different, therefore maybe only a basis for discussion and not for direct merge.

2020-01-19 22:04   
(edited on: 2020-01-19 22:20)
Right now in TestLink the idea has been:
modification_ts has to have a value only if there is a change.

We need to understand if a better check can solve this issue

Thanks for your analysis

a comment in the code said:
   * 20110115 - franciscom - fixed insert of null on timestamp field

Probably some choices are related to old versions of MySQL and how the null date and timestamp where managed.

Time ago 0000-00-00 00:00:00 was the NULL value for MySQL.

May be the right thing to do in the future will be change db to allow really NULL in the modification_ts fields

What we can do is check and if modifier_is NULL, set date to NULL when extrating from DB

2020-01-19 22:43   
Proposed fix using a different check, please try it [^]
2020-01-20 14:55   
Can confirm that this fix works on 1.9.19.
2020-01-20 16:40   
@vti, great to know