Mantis Bugtracker          
testlink.org

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002344TestLinkTest Project Managementpublic2009-04-07 12:152010-10-09 08:00
Reporterveerappajibs 
Assigned Tofman 
PrioritynormalSeverityfeature requestReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Fixed in Version1.9 RC 1 
Summary0002344: Private test project
DescriptionWe had a use case wherein the QA engineer needs a new private site for feeding testcases for his own projects, and wants to keep control about who browse and execute his testcases. So he creates a new testlink project, marking it as Private, and providing access only to himself, a coworker and his manager. Since there are two modules for executing, he assign himself to one and left the other to his coworker.

An option should be present on the Project Page , i.e a new option to choose a project to be private or Public.
Additional InformationImplementation strategy as i found out

A new column in TestProjects table wherein the column say option_private is to be created.

and in Projectedit.php make an option so that the project unless it is made public is not available to anyone except the admin/owner of the project.

a function which hides the private project by not inserting a value to user_projects_role.

Just similar to the below public/private option in Mantis issue reporter.

TagsNo tags attached.
Database (MySQL,Postgres,etc)
Browser
PHP Version
TestCaseID
QA Team - Task Workflow Status
Attached Files? file icon private_attribute.odt [^] (13,481 bytes) 2009-04-29 13:26

- Relationships

-  Notes
(0006241)
mhavlat (reporter)
2009-04-07 15:14

I can accept different (cheaper) approach with the same result:
Projects are not listed in top combo-box menu in the case that user has "no rights" project right.
Note, that you can setup default role from guest to no_right (for auto-create feature).

Is it ok for you? Explain if not. Thanks.
(0006242)
veerappajibs (reporter)
2009-04-07 15:37

Ya its Ok for me


And i accept your approach to be a better one
(0006247)
mhavlat (reporter)
2009-04-07 17:13

Acknowledged (target could be 1.9)
(0006272)
fman (administrator)
2009-04-08 16:29

@Martin:
are you sure that this has not impact on Permission system based on roles ?
Ask Andreas before doing any implementation or better assign this to him (he knows very well roles system)
(0006276)
veerappajibs (reporter)
2009-04-08 16:47

Hi i think fman is right, why dont we do it by doing it with roles system as i earlier suggested? by overriding the default testlink by inserting a <no rights> role to each private project in table User_testproject_role
(0006604)
fman (administrator)
2009-04-27 14:43

To semplify massive role assigned, bulk feature has been added => 1.9
(0006621)
mhavlat (reporter)
2009-04-27 17:44

What if a new user account is created? It receives guest role for such private project automatically then. It means that you must develop another level of checking.

Regarding performance: list of available projects should be given one time during login and stored in session data for all work. So performance will be improved :-)
(0006625)
fman (administrator)
2009-04-27 19:08

>>What if a new user account is created? It receives guest role for such private >>project automatically then. It means that you must develop another level of >>checking.
Humm, may be a solution is to change how we are manage test project roles, then when creating a new account we will automatically add with <no right> on every existent test project.
But when you create a new test project what to do ?
Again add an option to set all user to <no rights>

really this solution start to smell bad.

Think better thing to do is:
a) accept this as workaround, not a bad one
b) ask Andreas to understand how this new attribute for test project, and then for test plan also, can have impact on role logic and code.

Meanwhile this is VERY LOW priority, IMHO.

>> Regarding performance: list of available projects should be given one time
>> during login and stored in session data for all work. So performance will be >> improved :-)
who has talked about performance ?
what and where are these performance problems ?
(0006854)
fman (administrator)
2009-05-13 15:36

Development started
(0006856)
mhavlat (reporter)
2009-05-13 19:01

@Francisco,
I disagree with new attribute for rights limitation. The current system is consistent and able to care about the problem.
Reasons:
1. performance: rights are nearly all page part and additional minor dependence is not wanted
2. Administrator must see also private projects and plans. It means that you must exception for exception
3. Bad for maintenance - try to write UML diagram for your proposal - it' far from simple approach

I'm going to reassign this issue to Andreas to make a decision. Andreas, could you look at? Thanks.
(0006864)
schlundus (reporter)
2009-05-13 23:06

Discussion no longer necessary, as code already committed
(0006867)
fman (administrator)
2009-05-13 23:38

>>The same should apply to test plans. But the combination TestProject Private >>TestPlan public doesn't make sense. So if a Testproject with existing plans >>goes from public to private all PLan also should go from public to private. >>For the reverse transition the user should be asked
I will check ODT but I think I've written something similar
(0011729)
fman (administrator)
2010-10-09 08:00

Release 1.9 RC1

- Issue History
Date Modified Username Field Change
2009-04-07 12:15 veerappajibs New Issue
2009-04-07 15:14 mhavlat Note Added: 0006241
2009-04-07 15:14 mhavlat Status new => feedback
2009-04-07 15:14 mhavlat Summary Feature Request => Private test project
2009-04-07 15:37 veerappajibs Note Added: 0006242
2009-04-07 17:13 mhavlat Note Added: 0006247
2009-04-07 17:13 mhavlat Status feedback => acknowledged
2009-04-08 16:29 fman Note Added: 0006272
2009-04-08 16:47 veerappajibs Note Added: 0006276
2009-04-27 14:43 fman Note Added: 0006604
2009-04-27 17:44 mhavlat Note Added: 0006621
2009-04-27 19:08 fman Note Added: 0006625
2009-04-29 13:26 fman File Added: private_attribute.odt
2009-05-13 15:36 fman Note Added: 0006854
2009-05-13 15:36 fman Status acknowledged => assigned
2009-05-13 15:36 fman Assigned To => fman
2009-05-13 19:01 mhavlat Note Added: 0006856
2009-05-13 19:02 mhavlat Assigned To fman => schlundus
2009-05-13 23:05 schlundus Assigned To schlundus => mhavlat
2009-05-13 23:06 schlundus Note Added: 0006864
2009-05-13 23:38 fman Note Added: 0006867
2009-05-14 12:39 mhavlat Assigned To mhavlat => fman
2010-09-30 18:24 fman Status assigned => resolved
2010-09-30 18:24 fman Fixed in Version => 1.9 RC 1
2010-09-30 18:24 fman Resolution open => fixed
2010-10-09 08:00 fman Note Added: 0011729
2010-10-09 08:00 fman Status resolved => closed



Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker