Member release lock notification + lock

[khoppe]

While using Integrity it will sometimes happen that a user likes to lock a member which already have an exclusive lock from another user.

Today the first user have either the possibility to also lock same member revision, and then to talk with the other user when he will be ready with it's change,

OR to look on a regular basis when he will release his lock either by check-in or with "remove my lock". (=> Lock removed => everything is ok, first user have his lock.)

After the check-in it is possible that between the CI and the time the first user get's knowledge of it, another user has done an exclusive lock on the member's new revision.

The first user has again the same problem like described in the first two sentences of this entry.

My suggestion for the RfC is the following:

If one user have an exclusive lock on one member, and a second requests also an exclusive lock, then the "Check-in" or "Remove my lock" of the first user should have the following effect:

the lock of the second user should be moved onto the new member's revision, and the second user should be notified within his Integrity client  (new info icon in the menu bar) that he has got the requested exclusive lock.

Advantage of such a function:

The user who wants to have the lock does not have to search whether locks has got released (maybe several times, might be combined with the need to contact other user's that they shall release their locks), but only initiates a lock request and will get the requested locks (on new member revision for check in's OR on existing member revision if other user only removed his lock) as soon other users are ready.

[mrump]

First of all:

- "exclusive" means "there can only be ONE"

Depending on the locking Policy Settings in your Setup, IMHO your idea is already implemented.

Scenario:

User1 has an exclusiv Lock on Member1. Rev.1.1

User2 wants to edit Member1 as well; but when he does a checkout he can only get a "non exclusive lock" (there is an Option for checkouts that implicitly downgrades the request)

Now User1 checks in his changes and creates Rev 1.2

User 2 will not notice that, as his Focus was and is still on Rev 1.1 (which is in many cases exactly what is wanted, e.g. working in different devpathes)

Solution for you idea:

write a Trigger script and configure it to run after a checkin event:

Pseudo code:

1. find all locks on old Revision

2. move all "non exclusive" locks to the new Revision

3. send a notification to the affected users

[khoppe]

Hello,

as an answer to your post:

"exclusive" means "no one else will set next member revision".

To your scenario: This won't change much, except from this:

1. Event Trigger will fire for every Checkin Event, which will cause many additional workload on the system.
2. User2 will be notified by mail (advantage).
3. User2 needs to read his mails to get notified (no benefit compared with "needs to check the member").
4. Another user is able to again get exclusive lock before User2 can.
5. Move non-exclusive lock to new head revision won't avoid point 4.

Another point is:  Leaving a member's revision onto a certain value might take place in different DevPaths. Here we very often will have branches on the members. But it will also happen in case of Member archive shares. But from my opinion it does not have to do with the idea raised.

My basic intention is to get an exclusive lock automatically if I'm second in line after another exclusive lock without additional activity.

It would only be good to get a notification as soon the lock has been set to my id.

[mrump]

Ah, OK now i see your use case:

You are talking about something like a "pipeline" for exclusive locks (like gettings waiting number in an office)

Sorry, I thought you where talking about 2 exclusive locks (which would be a paradox).

Nevertheless IMHO your idea should be possible using Triggerscripts and one or two Member-Attributes.

The Member Attribute can store your "Pipeline" per member, individually for each project you re-use an archive in (unfortunately this does not apply to devpathes, so you would have to cover that inside you attributes)

[khoppe]

Hi,

I don't like to script anything what is an existing feature on competitor products.

Each time I start scripting I create something around the tool'S core which needs to be checked at each upgrade once again.

This is why I raised this idea.

And this is why I don't agree to create such a function with a script.

[tdalon]

Quote: If one user have an exclusive lock on one member, and a second requests also an exclusive lock, then the check-in of the first user should have the following effect:

replace check-in by check-in or remove his lock

[khoppe]

Of course you are right. I already described in first sentence, but did not repeat in the suggestion itself.

Now it is. Thanks