Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Operation Advisor for check-in operation

Questions
Tags
Users
Badges
Stefan Hoffmann
(144●2●18●20) Nov 20 '12, 1:43 a.m.
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.

0 votes

Comments
Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Nov 20 '12, 1:53 a.m.
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.

Stefan Hoffmann
Nov 20 '12, 2:15 a.m.
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".

Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Nov 20 '12, 6:31 p.m.
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?

Stefan Hoffmann
Nov 20 '12, 2:45 a.m.
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.

Stefan Hoffmann
Nov 20 '12, 3:26 a.m.
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).

1 answer
6,404 views
0 votes

One answer

Permanent link
Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (30.1k●3●34●35) Nov 20 '12, 6:43 p.m.
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.

0 votes

Comments
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Nov 21 '12, 6:44 a.m.
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

Register or log in 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.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 11,105

Question asked: Nov 20 '12, 1:43 a.m.

Question was seen: 6,404 times

Last updated: Nov 21 '12, 6:44 a.m.

Confirmation Cancel Confirm