Mantis Bugtracker 

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008731TestLinkRequirement Managementpublic2019-07-31 12:102020-01-20 16:40
Assigned Tofman 
StatusresolvedResolutionno change required 
PlatformOSubuntuOS Version18.04
Product Version1.9.19 (2019 Q1) 
Fixed in Version 
Summary0008731: last change made by undefined
DescriptionRequirement 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.

Steps To Reproduce"Navigator" - "Requirement Specifications" - any requirement - Action - view history.
Additional InformationErrors 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
TagsNo tags attached.
Database (MySQL,Postgres,etc)mysql 5.7.27-0ubuntu0.18.04.1
PHP Version7.2.19-0ubuntu0.18.04.1
QA Team - Task Workflow StatusTBD
Attached Filespng file icon undefined-2.png [^] (37,138 bytes) 2019-07-31 12:10

jpg file icon testlink_compare.jpg [^] (307,697 bytes) 2019-08-01 15:51
jpg file icon reqRevCreateTs.jpg [^] (95,467 bytes) 2020-01-19 09:11

- Relationships
related to 0008736resolvedfman Requirement versions compare page: user reported as 'undefined' 

-  Notes
fman (administrator)
2019-07-31 21:17

please provide very detailed steps to reproduce, that allow recreating a similar scenario.
I need a test case.
vti (reporter)
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
fman (administrator)
2019-08-01 15:55

fman (administrator)
2019-08-02 08:09

tested on latest code from github, using just one user.
unable to reproduce
vti (reporter)
2019-09-05 10:28

Can't find any additional specific info for reproducing purposes, sorry.
Will keep you informed if anything changes.
heju (reporter)
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.

fman (administrator)
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

fman (administrator)
2020-01-19 22:43

Proposed fix using a different check, please try it [^]
vti (reporter)
2020-01-20 14:55

Can confirm that this fix works on 1.9.19.
fman (administrator)
2020-01-20 16:40

@vti, great to know

- Issue History
Date Modified Username Field Change
2019-07-31 12:10 vti New Issue
2019-07-31 12:10 vti File Added: undefined-2.png
2019-07-31 21:17 fman Note Added: 0029060
2019-08-01 15:50 vti Note Added: 0029062
2019-08-01 15:51 vti File Added: testlink_compare.jpg
2019-08-01 15:55 fman Note Added: 0029063
2019-08-02 08:09 fman Note Added: 0029064
2019-08-02 08:09 fman Assigned To => fman
2019-08-02 08:09 fman Status new => feedback
2019-08-05 16:38 fman Relationship added related to 0008736
2019-09-04 21:04 fman QA Team - Task Workflow Status => TBD
2019-09-04 21:04 fman Status feedback => resolved
2019-09-04 21:04 fman Resolution open => no change required
2019-09-05 10:28 vti Note Added: 0029131
2020-01-19 09:11 heju File Added: reqRevCreateTs.jpg
2020-01-19 09:30 heju Note Added: 0029423
2020-01-19 09:32 heju Note Edited: 0029423 View Revisions
2020-01-19 09:33 heju Note Edited: 0029423 View Revisions
2020-01-19 09:36 heju Note Edited: 0029423 View Revisions
2020-01-19 09:41 heju Note Edited: 0029423 View Revisions
2020-01-19 10:08 heju Note Edited: 0029423 View Revisions
2020-01-19 22:04 fman Note Added: 0029425
2020-01-19 22:19 fman Note Edited: 0029425 View Revisions
2020-01-19 22:20 fman Note Edited: 0029425 View Revisions
2020-01-19 22:43 fman Note Added: 0029426
2020-01-20 14:55 vti Note Added: 0029434
2020-01-20 16:40 fman Note Added: 0029435

Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker