Mantis Bugtracker          
testlink.org

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004862TestLinkUsers and Rightspublic2012-01-10 15:442012-09-01 19:59
Reporterfrl 
Assigned Tofman 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformWAMPOSWindowsOS VersionSeven
Product Version1.9.3 (2011 Q3 - bug fixing) 
Fixed in Version1.9.4 (2012 Q3 - bug fixing) 
Summary0004862: Users rights on requirements are bypassed with interproject requirements relations
DescriptionWhen a user does not have rights on requirements of project A (guest profile for example), he has possibility to view and even modify a requirement on this project A, when he access it via the relation table of a linked requirement defined in another project B (on which he has requirement view rights)
Steps To Reproduce- configure your server with param $tlCfg->req_cfg->relations->interproject_linking = TRUE;
- define two projects PRJ-1, PRJ-2
- create 2 requirements REQ-1 in PRJ-1, REQ-2 in PRJ-2
- add a relation between REQ-1 and REQ-2
- define a user user1 with default role guest
- assign test project rights for user1 : leader on PRJ-1, guest on PRJ-2
- login with user1 and select project PRJ-2 => user1 can't access requirement specification (this is OK)
- now select PRJ-1 as current project
- select REQ-1 to display it via Requirement Specification
- click on the hypertext link REQ-2 displayed in the relation table of REQ-1
=> user1 access to REQ-2 even for edition, via the dialog window displayed by openLinkedReqWindow() call (this is KO, user1 has no rights to view or edit REQ-2)
TagsTO BE FIXED on 2.0
Database (MySQL,Postgres,etc)Any
BrowserIE 8
PHP Version5.3.3
TestCaseID
QA Team - Task Workflow Status
Attached Files

- Relationships

-  Notes
(0016218)
fman (administrator)
2012-01-11 19:38

Think all related requirements (no matter test project they belong to and USER RIGHT on each test project) have to be displayed.
If we do not proceed this way we will generate confusion, because different users will get different views.
User can access always in READONLY Mode req, surelly Read/Write mode has to obey user rights on each test project
(0016219)
fman (administrator)
2012-01-11 21:04

1.9.x
http://gitorious.org/testlink-ga/testlink-code/commit/590eb21ac88b5a0cc0a039c55ccf9fcb81d7cdd5 [^]

please try to port this code to your 1.9.3, test and give us feedback
(0016222)
frl (reporter)
2012-01-12 16:19
edited on: 2012-01-13 08:35

I agree that the content of relations table must always be the same :
If user1 has rights to view REQ-1, all the relations set for REQ-1 must be displayed, even if user1 has no rights on related requirement (REQ-2).

I tested your code on my platform : Your fix prevents unauthorized edition of REQ-2 by user1 (this was clearly the most important in my opinion)

Nevertheless, he still has access to details of REQ-2 in the popup window, for a project on which he may have no right at all.
So (if possible), I would propose this enhancement to the behaviour :

- If the user does not have any right (view or edition) on the related requirement (REQ-2), display the relation to REQ-2 as a simple label without link or as a link to an error msg window in the Related Requirement column of relation table of REQ-1
=> this way, user1 has only information on the relation itself without seeing the details of REQ-2 and all users have the same view with all relations defined for REQ-1

- If user has view or modify rights on the related req (REQ-2), display the relation to REQ-2 as a link to have possibility to display the dialog window with details of REQ-2, always in read-only mode (as your code do now).

(0017356)
fman (administrator)
2012-09-01 19:59

1.9.4 released

- Issue History
Date Modified Username Field Change
2012-01-10 15:44 frl New Issue
2012-01-10 20:46 fman Assigned To => fman
2012-01-10 20:46 fman Status new => assigned
2012-01-11 19:38 fman Note Added: 0016218
2012-01-11 21:04 fman Note Added: 0016219
2012-01-11 21:05 fman Tag Attached: TO BE FIXED on 2.0
2012-01-11 21:05 fman Status assigned => feedback
2012-01-12 16:19 frl Note Added: 0016222
2012-01-12 16:19 frl Status feedback => assigned
2012-01-13 08:35 frl Note Edited: 0016222 View Revisions
2012-01-16 19:01 fman Status assigned => resolved
2012-01-16 19:01 fman Fixed in Version => 1.9.4 (2012 Q3 - bug fixing)
2012-01-16 19:01 fman Resolution open => fixed
2012-09-01 19:59 fman Note Added: 0017356
2012-09-01 19:59 fman Status resolved => closed



Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker