|Anonymous | Login | Signup for a new account||2020-02-28 09:00 UTC|
|Main | My View | View Issues | Change Log | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001155||TestLink||Database General||public||2007-11-01 04:06||2010-05-01 20:35|
|Fixed in Version||1.9 Beta 2|
|Summary||0001155: builds table should have a date or timestamp field|
|Description||The builds table should contain a field for creation_date or creation_ts to track when a build record was created.|
|Tags||No tags attached.|
|QA Team - Task Workflow Status|
edited on: 2007-11-04 00:57
Again this change to schema must be discussed before done any change to db.
Need to understand why this time stamp is important, becasue if this is the case, then other object like:
tesprojects and testplan must have similar attribute.
And then why not add information about who has created it
and who has done last change?
is this information so important for a build ???
discuss with dev list before implementing.
If accepted, scripts must be changed for every db type
|This would allow users to sort builds by when they are added. As you suggest this would be useful for other types of objects too. It would also be useful to know who has changed or created providing a mechanism more similar to an audit log.|
This would allow users to sort builds by when they are added
is enough add config option to order by (internal)ID
I expected that user can add a date of build release date according to title of issue. It make sense for me. Offered default value is the date when the record is created of course.
The information who and when create the build is stored in audit history.
Then requirement has changed, becuase what you need is to add a date as a build attribute.
Need to change:
- DB SCHEMA
- build management functions and screen
If the date is being stored in the audit history using this would fulfill the original enhancement outlined in this issue.
We just need to make this history usable from the build related pages in the UI.
Is the audit history built to be used this way? I can see how this could be useful in many areas of Testlink as a method of sorting/filtering other than just builds.
Disagree, if is a BUild attribute must be present on Build table.
Do not like this kind of solution.
History table can be deleted/purged and this ifno will be lost.
Add new field following on Builds table using our standards name and col type
Reminder sent to: schlundus
Andreas, could author of audit feature draft his meaning? Thanks.
There are some possible approaches
First and the most general one:
Every item which can be created has a valid_from field. This field could be the creation date or it could be a date in advance. So i are creating builds in advance then you can also give a valid_from date in the future.
Every item which can be deleted has a valid_to field. This field could be the date of deletion date, or it could be a date in future. Of course this field only makes sense if one doesn't delete it really from the db...
but normally if one wants to create reports on stuff, it's not really deleted
With this mostly generic approach you can:
Add items in advance.
Specify a time range in which the item is valid.
Do reports who are taking into account when which item was valid.
You can take this approach for all objects an application used. eG. for users: one can easily create a (temporary) user whose account is valid from now to 2weeks or something else.
Or assigning roles. So if one knows that a certain user is only executing tests for a certain period of time (because of deputyship, or lack of resource) then one can assing a tester-role only for two weeks. And the application assures that the tester role is only valid during the two weeks. No further manual role-dropping is needed.
Of course this approach takes a lot of changes (-: And the application must do the logic of taking the valid_from and valid_to in all actions into account. But the results is nearly the most flexible application (-:
Anyway, a change of a build results in an entry in the audit log and can be examined with the event viewer. With the appropriate changes (a small code snippet) One can easily invoke the event viewer showing all events related for this specific object. I did this already for some objects like projects....
If the general approach is too much effort then:
A build field for tracking the creation date can be useful to sort the builds in those cases where the naming of the builds require a use-specific sorting. So in normal cases the builds are created in a timely ordered manner...
But it believe one can achieve the same result by sorting by build_id (not checked) because it a auto-increment value (i believe). So the latest build always has the highest number. In those cases where the users created builds not timely ordered (create build1, created build3,ooops and the created build2)
then creation_date and the build_id approach is wrong
The solution is either:
- take the generic approach, so the user can create the order in time
- sort always be build_id
- sort by build_name (if it makes sense)
For history tracking purposes no further actions are required, because all those actions are contained in the event log. And because its easily possible to call the eventviewer showing only events related to a specific object
Azl' comment (0003720) is nearly 100% correct. But the event log should be used for sorting stuff. This should be achieved with other stuff like build_id, uild_name
Thanks Andreas for this great analyse. I try to summarize.
The using audit log is a simple solution to cover this feature request without potential for enhancement. We support a simple solution.
Implementation of valid period pattern will allow to modify dates by user (to fit difference between edit and real build date. It refunds a boolean parameter open/close by more sophisticated way. It could naturally improve milestone functionality.
Is the second one clearer from OO point of view?
Using audit log to support this feature is wrong.
If you use as example file system, you can see that creation date/ owner
and last change info are file object attribute, and you have this info always, without need to enable audit trial feature.
Audit trial is useful for other porpouse.
Waht if one TL user choose to disable audit trial?
Anyway IMHO problem and confusion with this issue arise because requirement is not clear.
If you read carefully complety discussion seams we are facing now two different requeriments:
1. add creation date and use it for sorting build list
this creation date is time when build record was created on TL database,
(i.e. a very low level technical data) and user CAN NOT CHANGE it.
2. add a build release date.
I understand this date, like something similar to mantis release date.
Is a user managed data (a build attribute) that is used only to said
"In our shop we will create build xx on this date."
This date can be used to sort build list, BUT HAS NO enable/disable effect
on TL feature.
TL today manages the on/off concept Active/Inactive for TestProjects, Testplans,
builds, and seems to be enough.
I do not understand added value for normal users to order any item by creation date.
May be this info can be useful for an admin user and, as stated before can be found on audit log, but attention only till this log is not cleared.
Normally you can not maintain on-line forever audit logs.
One thing we all need to understand when we write a requirement or an issue,
- write as much as possible (with examples) to give enough info
to understand importance/usefulness of issue/requirement.
- More functional information, not more technical/development info on first
- Explain what we need not how to solve it.
Using validation period give more functionality but a lot of complexity on refactoring.
There are several questions:
. how important is this kind of feature for TL ?
. how important is for each kind of item TL manage ?
extending all application objects with this kind of feature is an overkill.
Better solution is keeping things as much simple as possible.
A good approach is a prototype => implement this feature on milestones,
see how difficult is, then think in problems applying this solution to other items.
If we want to use this valid_from/valid_to to show/hide things, we need to add this logic in every place.
I'm not saying is wrong, I'm just saying see not a lot of added value.
We have other testing regarding features to improve/implemente before this kind
Regarding a pseudo-simple solutions remeber this:
There is always simple solution for a complex problem, and normally is a wrong solution.
|There is one positive effect to have closing timestamp. We can have correct "total TC count" for builds. See 1508.|
|2007-11-01 04:06||azl||New Issue|
|2007-11-01 04:07||azl||Status||new => assigned|
|2007-11-01 04:07||azl||Assigned To||=> azl|
|2007-11-04 00:53||fman||Note Added: 0002505|
|2007-11-04 00:57||fman||Note Edited: 0002505|
|2007-11-06 04:40||azl||Note Added: 0002557|
|2007-11-06 20:43||fman||Note Added: 0002568|
|2008-06-18 21:08||mhavlat||Note Added: 0003702|
|2008-06-19 14:04||fman||Note Added: 0003712|
|2008-06-25 04:58||azl||Note Added: 0003720|
|2008-06-25 14:19||fman||Note Added: 0003721|
|2008-06-25 15:41||mhavlat||Note Added: 0003723|
|2008-06-25 23:09||schlundus||Note Added: 0003725|
|2008-06-26 14:33||mhavlat||Note Added: 0003728|
|2008-06-26 17:52||fman||Note Added: 0003732|
|2008-06-30 19:51||mhavlat||Note Added: 0003748|
|2008-06-30 19:58||mhavlat||Relationship added||related to 0001508|
|2009-05-14 02:22||schlundus||Assigned To||azl => fman|
|2009-07-27 22:20||fman||Status||assigned => resolved|
|2009-07-27 22:20||fman||Fixed in Version||=> 1.9 (DEV)|
|2009-07-27 22:20||fman||Resolution||open => fixed|
|2010-05-01 20:35||fman||Status||resolved => closed|
|Copyright © 2000 - 2020 MantisBT Team|