Temporary Library Access Via Workflow

[TomU]

I am looking for suggestions on how to allow users to create and update library objects without opening up the entire library to them.

Currently when a user wants to make a change to a library part I simply add them to the role with the appropriate permissions and then remove them when they're done. The danger with this is that they could inadvertently change much more than intended (anything in the library).

I have considered using a "Library - Pending" folder, but then I have to manually move the objects they want to change into that folder first before they can check them out. Then I have to move them back when they are done and the changes are approved. Is there a better way to do this?

In a perfect world I would like a change request to trigger a workflow that automatically allows the user to access the necessary objects and then locks them back down after the changes are approved. Is there a way to use a workflow to either (a.) move the files back and forth at the proper point in the process or (b.) allow access to only the affected objects long enough to make the changes without opening up the entire library?

Thanks.

Tom U.

[ssenthil]

Hello Tom

did you take a look at lifecycle states and ACLs. In-Work (Read, Modify), Underreview(Read), Released(Read) can address your requirement.





Thank you and have a great time.

Best Regards

Swamy Senthil

Principal Solutions Architect, Swasen Inc

swamy.senthil@swasen.com(Email); 909 800 8423(M); 973 324 2729(W); 866 908 6561(F);

[TomU]

Currently everything is at “In Work” in the library. Typically we do not revise library parts when making changes (or track those changes on the history table of the drawings) since these parts are used primarily as templates to create other job-specific parts from.

If I am understanding you correctly, I would do the following.
1.) Change the lifecycle state of all existing library objects to released.
2.) Change the permissions so users cannot modify released objects but can modify in-work objects.
3.) Create a workflow that changes the lifecycle state of the objects we want to alter from released to in-work.
4.) Have the user make the changes.
5.) Have the workflow finish by promoting the affected objects back to released.

The major issue I see with this method is that it leaves the entire library context open to new objects being created and subsequently modified until they are promoted. Right now our users are not allowed to create objects in this library context at all. I’m not real excited about opening that up. I guess it might work if there was a “created by” or “owner” permission that could be used so that other designers couldn’t see newly created library parts that they didn’t create until they were promoted to released.

[ssenthil]

Usually when a change is required for a released object, it will be revised. When you revise an object, it will take the first lifecycle state "In-Work". When releasing the revised object, set the state of the earlier version to "Obsolete" or equivalent to which only WC admins have read access.



There are few options available for preventing all the users from creating the objects. One can create a group "designers" and provide create/modify access to designers when the state is inwork. Other options depend on how the change/promote process is initiated. By tweaking ACL & States, profiles, workflow ad-hoc ACls one can meet the requirements you addressed below.



Swamy Senthil

Swasen Inc.

[atre.shreyas]

Tom,

You can grant modify permission using life cycle.for example: life cycle is as followsOpen-In work- approved- released- obsoleted and you want to grant modify permission only in "In Work" state for designer(only one user), you can use below approach

1.Modify the objects team template and add role Designer (you can add role as per your setup)

2.Modify the life cycle and grant modify permission in "In Work" state for designer role3.When you want to give modify access to particular user add that user into objects team in designer role.

If you want to grant permission only using workflow activity then grant modify permission on “primaryBusinessObject” in activity variables(make sure workflow is running on the object for which you want to grant the permission )
See attached for details

--Shreyas

[TomU]

Interesting. So do life cycle access control permissions supersede domain permissions?

Tom U.

[atre.shreyas]

Yes. life cycle access control permissions supersede domain permissions.see attached mangae security window for desc user

Thanks,

Shreyas