Mantis Bugtracker 

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002376TestLinkUsers and Rightspublic2009-04-14 16:142010-05-01 20:28
Assigned Tofman 
PlatformOSOS Version
Product Version1.8.1 
Fixed in Version1.9 Beta 4 
Summary0002376: Does not displaying test cases if user of that test cases is deleted
Descriptionif any user has been deleted from the list then the test cases created by him/her is showing fatal error.
suppose user "A" has created 10 test cases and if user B(admin) delete user "A" then the test cases created by user "A" does not getting displyed by testlink. it is showing fatal error.
TagsNo tags attached.
Database (MySQL,Postgres,etc)
PHP Version
QA Team - Task Workflow Status
Attached Filesjpg file icon Testlink1.8.1_error.JPG [^] (186,737 bytes) 2009-04-15 12:01

- Relationships
parent of 0002383closedschlundus Execute button showing fatal error. 
parent of 0002906closedfman It´s not possible to delete user 
has duplicate 0002407closedfman Error when viewing test case specification 
has duplicate 0002504closedfman Test cases cannot be viewed/edited due to programming error 

-  Notes
amitkhullar (reporter)
2009-04-14 17:16

I would suggest you disable users rather than deleting them since this causes an issue in the database

fman (administrator)
2009-04-14 23:45

@Amit: I disagree - user must be deleted and system must work OK.


Please detailed error message please.
amitkhullar (reporter)
2009-04-15 11:05

@Fman - I disagree, user should only be allowed to delete if no TC / TP / T.Exec has been done by him, basically referential integrity, if any relation does exist then make him deactivate rather than delete, since when u run reports and try to find the actual user who did create / update /execute a TC etc. it shouldnt show blank user name, but maintain the history

sumeet_psl (reporter)
2009-04-15 12:00
edited on: 2009-04-15 12:02

I have tested this scenario again. It is showing the same error message.

The user who has created and executed this test case has been deleted and when we tried to view this test case from specification tab then it is showing below error. I have uploaded the snapshot of error message.

Error Message:

Version 2
Created on 23/03/2008 16:06:01 by
Fatal error: Call to a member function getDisplayName() on a non-object in /opt/lampp/htdocs/testlink1.8.1/gui/templates_c/%%2E^2E1^2E11686C%%tcView_viewer.tpl.php on line 179

fman (administrator)
2009-04-15 20:28

How valuable can be know that a user that has quit, wsa author of a test case or test plan?
Anyway we can have problems when we will enable Foreing keys.
I will not going to remove possibility to delete a user.
See what happens on Mantis when user is deleted => only internal user code is retained, but user can be deleted.
Doing lot of controls regarding referential integrity before deleting a user is not worthwile.
Right nigth priority is to 'fix' error, in future we will stufy what will be better solution.
Julian (reporter)
2009-04-29 20:31
edited on: 2009-04-29 20:34

how about leaving the user data in database. set a deleted-flag and just dont show it in the gui where this information is not necessary..

in my opinion this information must not get lost.

fman (administrator)
2009-04-29 23:29

As stated before I disagree, see how mantis works.
and in addition to use a delete or disable attribute we need to:
- change db schema
- change delete procedures
mhavlat (reporter)
2009-04-30 04:37

1. User should be 'undefined' for the case.
2. Administrator could be warned that there is user related work. + recommendation to disable account.
schlundus (reporter)
2009-05-01 00:37

My vote is also the proposal of Julian
mhavlat (reporter)
2009-05-12 12:23

Julian proposal is fine for 1.9 version (need DB change).
Regarding 1.8 version we should disable 'delete user' and do 'inactivate user' with explanation.
Is it ok for you Andreas? Do you plan to fix it within 1.8.3 version?
fman (administrator)
2009-05-12 14:23

Then how this will work?
if user has not been used on other tables will be really deleted?
Julian (reporter)
2009-05-12 14:27
edited on: 2009-05-12 14:28

another thing to think about:

what happens if you try to create a user with the same loginname as the deleted one. Could be no problem... :)

mhavlat (reporter)
2009-05-12 15:36

It's not a problem as all relation are done via ID.
Julian (reporter)
2009-05-12 15:50

thats clear. i meant that the login routine has to be adjusted. a login can only be possible for users that are not deleted. but thats clear to you for sure ;)

because right now i guess when trying to login when 2 users having the same loginname would cause error.. (havn't looked at the code - so if i am wrong - great ;) )
fman (administrator)
2009-05-13 22:51

@Dev team:
field active is present on users table => no db schema change needed
Julian (reporter)
2009-05-14 17:42

active is of type TINYINT(1)
and this is used right now to set user active or inactive right ? so a db change is needed?
fman (administrator)
2009-05-17 18:04

I think we have all we need:
user can be INACTIVATED, and then he/she will not be able to login, and all info about his/her identity remains on system i.e. data integrity as requested by amit is OK.
LOGIN NAME of inactve users CAN NOT BE REUSED, and this is OK.

2. delete must works as done today, just do not crashing system
IMHO there is no need of logical delete, because we ALREADY HAVE IT, using ACTIVE/INACTIVE attribute.

If we remove foreing keys regarding user id, we can mantain work done by user on system, and just display AS DONE BY MANTIS a fixed string with user Id, to indicate that he has done work has been deleted.

Then only thing to do fix points where today we crash, but on user management add only suggest when admin try to delete (as suggested by Martin) that may be is better to DEACTIVE user
schlundus (reporter)
2009-05-18 01:43

A quite simple solution is
active = 1 => active
active = 0 => inactive but can be activated again
active = -1 => inactivated and cannot be activated -> really disappears from system (but all data remains). On existing data the user will be shown with the suffix "Deleted!"
mhavlat (reporter)
2009-05-18 09:48

I'm fine with the solution by Andreas. Maybe the table of users should not include 'deleted' users. But a simple list of nicks below the table do the job. It could be less work against mark deleted and disabled actions in the main list. It's just idea. Mark deleted is also fine.

Francisco, I would like to show name of deleted users without change (not strike through like Mantis have). The information is still valid.
mhavlat (reporter)
2009-05-19 13:13

I'm going to disable delete for 1.8.3. I will consider analyses here for final solution on DEV.
mhavlat (reporter)
2009-05-20 10:11

Fixed in 1.8.3 code. Todo: documentation update.
fman (administrator)
2010-04-17 21:16

Users can not be deleted but deactivated

- Issue History
Date Modified Username Field Change
2009-04-14 16:14 sumeet_psl New Issue
2009-04-14 17:16 amitkhullar Note Added: 0006360
2009-04-14 23:45 fman Note Added: 0006371
2009-04-14 23:45 fman Status new => feedback
2009-04-15 11:05 amitkhullar Note Added: 0006379
2009-04-15 12:00 sumeet_psl Note Added: 0006381
2009-04-15 12:00 sumeet_psl Note Edited: 0006381
2009-04-15 12:01 sumeet_psl File Added: Testlink1.8.1_error.JPG
2009-04-15 12:02 sumeet_psl Note Edited: 0006381
2009-04-15 19:10 amitkhullar Relationship added parent of 0002383
2009-04-15 20:28 fman Note Added: 0006392
2009-04-15 22:32 schlundus Status feedback => assigned
2009-04-15 22:32 schlundus Assigned To => schlundus
2009-04-29 20:31 Julian Note Added: 0006679
2009-04-29 20:34 Julian Note Edited: 0006679
2009-04-29 23:29 fman Note Added: 0006681
2009-04-30 04:37 mhavlat Note Added: 0006694
2009-05-01 00:37 schlundus Note Added: 0006705
2009-05-12 12:23 mhavlat Note Added: 0006829
2009-05-12 12:24 mhavlat Priority normal => urgent
2009-05-12 12:24 mhavlat Severity major => crash
2009-05-12 14:23 fman Note Added: 0006832
2009-05-12 14:27 Julian Note Added: 0006834
2009-05-12 14:28 Julian Note Edited: 0006834
2009-05-12 15:36 mhavlat Note Added: 0006836
2009-05-12 15:50 Julian Note Added: 0006839
2009-05-13 22:51 fman Note Added: 0006863
2009-05-14 17:42 Julian Note Added: 0006886
2009-05-17 18:04 fman Note Added: 0006904
2009-05-18 01:43 schlundus Note Added: 0006917
2009-05-18 09:48 mhavlat Note Added: 0006918
2009-05-19 00:12 schlundus Assigned To schlundus => fman
2009-05-19 13:13 mhavlat Note Added: 0006944
2009-05-19 13:13 mhavlat Assigned To fman => mhavlat
2009-05-19 13:13 mhavlat Category Test Specification => Users and Rights
2009-05-20 10:11 mhavlat Note Added: 0006969
2009-05-23 00:44 amitkhullar Relationship added has duplicate 0002407
2009-05-23 00:44 amitkhullar Relationship added has duplicate 0002504
2010-02-08 17:03 mhavlat Relationship added parent of 0002906
2010-02-25 00:44 mhavlat Status assigned => acknowledged
2010-02-28 22:29 mhavlat Assigned To mhavlat =>
2010-04-17 21:16 fman Note Added: 0009758
2010-04-17 21:16 fman Status acknowledged => resolved
2010-04-17 21:16 fman Fixed in Version => 1.9 Beta 4 (Next public build)
2010-04-17 21:16 fman Resolution open => fixed
2010-04-17 21:16 fman Assigned To => fman
2010-05-01 20:28 fman Status resolved => closed

Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker