User can change value of a restricted timestamp, if he also changes Filed Against.
For attributes of type Type timestamp, a user who does not have permission to modify the attribute, can still erase the value and save the workitem if he also changes Filed Against. The user can also fill in the value, if it's currently empty. This completely bypasses the restriction.
Scenario: 1. Create a custom field of type Timestamp and add a presentation. 2. Create two Team Areas (you can leave them empty) 3. Create two work item categories 4. Assign each category to one Team Area 5. Create two users – user1 and user2 6. Assign the users to two different groups 7. Set the group permissions so that the Timestamp attribute can be modified by the group of user1 but not the group of user2 8. Log in as user1, create a workitem, fill in the Timestamp attribute and save 9. Log in as user2. Erase the value of the Timestamp attribute and change the Filed Against attribute value to whatever value (other than the current one). 10. Save workitem Expected result: Permission Denied is issued. Actual result: user2 is able to save workitem, and the value of the Timestamp attribute is changed to empty. This happens in both Eclipse and Web. Is this a bug or working as designed? |
Accepted answer
|
This "as designed" behavior has been identified, commented and documented on jazz.net using work item 152767
1 - restrictions for custom timestamp attribute are defined at PA level (root category) 2 - when you: - clear the timestamp value and - change the filed against, you change the Team Area the filed against / category is associated with. And this TA takes precedence regarding roles / permissions behavior. This is documented in: https://jazz.net/library/article/292 and https://jazz.net/library/article/291 and summarized in 152767 at comments 40, 41 and 42 To summarize - changing the Filed Against attributes changes the TA which changes roles / permissions. So clearing the timestamp value and changing to any category other that the root one (which holds the PA ones with the restriction) is allowed - behaves as designed This is confirmed if you do the same but select the root category (which holds the PA ones with the restriction): you'll get a permission denied. Seth Packham selected this answer as the correct answer
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.