It's all about the answers!

Ask a question

How Can I Grant Modification Permission on Work Item creationDate?


Chris Rowan (1136) | asked Aug 09 '13, 10:13 a.m.
We recently upgraded our application from RTC 3 to RTC 4. One of our plugins starting failing when trying to modify the creationDate field in work items. Looking at that attribute, I noticed that it was marked as read-only. I removed the read-only flag. Now some users were getting errors and others weren't when trying to save work items - "you don't have permission to perform the following actions: modify/creationDate".

 Investigating roles and permissions, I could not find a 'creationDate' field listed in the "Permitted actions -> save work item -> modify work item" list (Team Config -> Permissions area). I did find 'createDate' and so granted all users permission to modify this field. However, the same users were still getting the same error when trying to save a work item. I discovered that the users that could modify this field, had full (blanket) modify permissions set for their role.

I believe one of two situations exists here:
 1) the 'createDate' field and 'creationDate' field are the same, but granting individual permission to modify it is not working
2) the 'creationDate' is a hidden field from a permissions point of view, and modification privileges are only granted if a user has blanket modify permission.

I would suspect #2 as being more likely. Perhaps because it is a built-in field that is marked as read-only out of the box.

I would prefer not to have to grant all the users blanket modify permission, so I am looking for a better solution here.

Thanks,
Chris

Comments
Jared Burns commented Aug 09 '13, 11:57 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I'm not sure what's going on here, but I'm responsible for the part of the Jazz framework that enforces permission checks and I can at least chime in that we don't support anything like #2.


Mathew Kilner commented Feb 05 '14, 4:05 a.m. | edited Feb 05 '14, 4:56 a.m.

I have been doing some further investigation and I can confirm that Chris's observation regarding blanket modify permissions is accurate.

If I grant all modify permissions on a work item, either at the high level or by selecting each individual attribute I do not see an error.

If I remove any individual attribute then the error is seen.

Looking at the difference in the configuration xml between these edits it is fairly substantial. When all attributes are selected as modifiable there is a single xml element granting permissions. When any attribute is not selected I see an entry for each individual attribute.

So whether the behaviour is intentional or not it is clearly present.

I can recreate this issue at will in a test server. What is even stranger is that the error manifests on the first save of a newly created work item. I have looked over our code many times now an we do not attept to modify the creation date in any way so I am at a complete loss as to why we have this issue.

UPDATE: If I manually edit the configuration xml to grant modify permission for creationDate the error is resolved.

One answer



permanent link
Stephanie Bagot (2.1k1513) | answered Aug 19 '13, 6:14 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
By default the creation date attribute is a built-in field that is read-only - this saves the work item creation date and is usually not edited. OOB I don't see a createDate field, is this a custom field?
I think this may be working as designed and the creationDate (built in attribute) is not typically editable. I would recommend opening up a PMR with IBM Support and include your process template to confirm.


Comments
Mathew Kilner commented Feb 05 '14, 4:07 a.m.

Hi Stephanie, I added a longer comment to the original post. We are not modifying the attribute and the error occurs on the first save of a newly created WI.

Your answer


Register or to post 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.