It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,882
×6,114
×1,201
×889
×66
×56

question asked: Oct 21 '15, 6:15 p.m.
question was seen: 3,156 times
last updated: Oct 10 '17, 1:20 p.m.

Related questions

Is it possible to let a user acquire a lock but not release it?

0
Francisco Rodriguez (56●15●28) | asked Oct 21 '15, 6:15 p.m.
edited Oct 10 '17, 1:20 p.m. by David Lafreniere (4.8k●7)
 Hi,

I want to achieve the following: Once a user starts working in a file, the file should be locked and it should remain like that until it a validation is done. The user should not be able to release the lock of that file but it is done automatically (using some kind of participant extension).

Is this possible? 

Regards,
Francisco R.

Accepted answer

0
permanent link
June Boston (194●30●38) | answered Oct 21 '15, 7:41 p.m.

The permissions for locking and unlocking files are the same, presumably because only the same user can unlock something they locked (or a Jazz Admin).

Ignoring this permissions issue, you would have to develop a script/operational behavior extension to release the lock.  Maybe you should make this automation take both sides of the issue.  When a user starts working in a file, the file is locked by a script using some service account (maybe it can run as the system itself, haven't written any myself lately).  The script would then unlock it with the same service account when the validation is done.  I don't know how you want to determine "working in a file"; if you lock it when the user checks it out that could get annoying to the other users, but I don't know how your SCM is set up and utilized so maybe that is ok.  Regardless, sounds like a bunch of scripting is your option here.

David Lafreniere selected this answer as the correct answer
Comments
Francisco Rodriguez commented Oct 21 '15, 7:55 p.m. | edited Oct 21 '15, 8:11 p.m.

Hello June. What do you mean by "service account"?

June Boston commented Oct 21 '15, 8:03 p.m.

An account in your LDAP, or Tomcat registry or whatever you use, that isn't actually a person but instead is used by scripts or other processes, and has a big long complex password.  For example, the common reporting service account "rptuser" isn't logged into by any human, just other programs; I see one of these in most environments.  "Service account" isn't a CLM term, just a description; you would implement it as a normal account, making it a Jazz User (or a Jazz Admin if you need to).

In the example of this script: because only the user who locked a file can unlock a file, if the service account the script uses does all the locking/unlocking then your users won't be able to unlock the files, only the script account would (which it will do automatically after the validation).  The script's service account would need to be a member of the project and have a role that allows it to lock/unlock files, of course.  If you made it a Jazz Admin, it could probably work without being added to the project, and it could unlock files that your users lock.

Francisco Rodriguez commented Oct 21 '15, 8:12 p.m.

 Okay, I now understand. So, do you have any idea of how to trigger the script when the user edits the file?

June Boston commented Oct 21 '15, 8:20 p.m.

When you say edit, do you expect the users to probably have all files in their sandbox and only edit one of them?  If so... I'm not sure how to do that with Eclipse, though I'm sure it is possible.  Perhaps you could wait for the RTC event of a file being checked in from a sandbox to a workspace, and if that file wasn't previously locked you do so.

There are a lot of weird technical/business decisions relating to your needs and process you will have to make, and I haven't written extensions for source control behavior since CLM 3 so I don't think I could get more detailed on how to implement it.  This is just my theory on how to make CLM do what you need it to do, as extensions are useful to fill the gaps in CLM capabilities.

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.