It's all about the answers!

Ask a question

User can change value of a restricted timestamp, if he also changes Filed Against.

Eric Jodet (6.3k5111120) | asked Jun 18 '12, 4:34 a.m.
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.

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

permanent link
Eric Jodet (6.3k5111120) | answered Jun 18 '12, 4:38 a.m.
This "as designed" behavior has been identified, commented and documented on using work item 152767
1 - restrictions for custom timestamp attribute are defined at PA level (root category)
2 - when you:
- clear the timestamp value
- 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:
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

Register or to post your answer.