Operation Advisor for check-in operation
Is there a way to create an operation advisor for check-in operations? We have streams with "read only" components, so the user should not be alllowed to modify these special components. I am aware of the "Restrict Change Set Delivery to Components in a Stream" precondition, but this has to be configured for each stream (we have a general rule which we can apply). And it is a little late, we would like to prevent even change set creation for this forbidden components.
I know that a tricky user could work around this with some knowlegde (removing the flow target on his repository workspace, so we loose the "which component is forbidden" information), so we also need the deliver operation advisor, but we want to warn the user as early as possible, that he is doing things he should not. And this should be a server side operation, as we do not want to implement this precondition for the various clients (eclipse, cli, shell integration, etc...). As check-in works on the repository workspace, which is server side, this should be possible. |
One answer
Geoffrey Clemm (30.1k●3●30●35)
| answered Nov 20 '12, 6:43 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Based on the discussion around this question, I've created work item Allow a user to declare that if they are not allowed to deliver changes to a file, that the file should be loaded into the sandbox as read-only (242009)
This is of course not the original request (i.e. allow process preconditions on the checkin operation), so that is still the behavior you would prefer, please feel free to submit a work item with that request. Comments I think this could also be a good interim step to get to a full blown pessimistic locking capability. For example if you have a property on stream/component or file type/individual file level to set it to pessimistic locking, SCM could load these files read only and the client could hook into making it writable including checking for a lock and setting a lock.
|
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.
Comments
Ideally, you'd really want the user to be warned when they first try to edit the file wouldn't you? I.e. you'd like the file to be read-only in the file system? Otherwise, the user could busily make all sorts of changes (periodically saving them), only to discover at checkin time that they shouldn't have been changing that file.
Yes, this would be the perfect solution. But the "read only" status on the specific components relay on the context, the stream where they are used. So for the one stream it is ok to write, in the other stream it is not. Thus we can not apply file based "read only" flags. At the end we would need some sort of os-level integration (as this is the only place were we can really asure this sort of file protection) which is to much effort for us. So the check-in is the best next available "check point".
A few comments:
First, note that RTC's design is that a workspace is owned by a user, and that user should be able to do anything they want in it. So a process should never prevent a user from checking in changes to their workspace.
On the other hand, it is very reasonable for a user to want to be notified that they are changing a file that they won't be able to deliver. But currently, RTC does not provide you with a way to do that (until you actually try to deliver the changes).
So in terms of how to phrase the RTC enhancement request, would you want RTC to make those files read-only in the loaded sandbox, so the user doesn't update them by mistake?
As the read only flag applies only to some specific streams. We can not generally set the read-only, as for some streams it is ok to modifiy this files (and the read only flag would be false). But in other streams we need this read only flag, but for same configuration.
I just see that the "read only" flag on a file is not an scm property (changing a file in eclipse to "read only" does not produce unresolved status).
So: Can we intercept the "load" process on the client side to manually set the "read only" flag in the needed scenarios? That would be a nearly perfect solution. Has to be implement for each client, but we can live with that (and at first we would take the eclipse client).