Library Data Read-Only for a Role

[ColruytTeam]

Hi Community,

Can any one suggest me a way to keep library data read-only for a particular role.

I want only one role should have write access to that library. The remaining roles should only read the data and can clone the objects from that library.

Thanks in advance.

[jhorber · Accepted solution]

Hello Colruyt Team 

Will it be applicable for all the objects in the library?

--> It will be necessary to compute the collection with API script or to configure an operator.

Do I have some  single point of control

--> Yes you can trigger the processing by clicking on a menu item of the root object (ex: Library)

[ColruytTeam]

Hi Jerome,

Thanks for your explanation.

I want the data to be protected in Library level. If I apply immutability on Library level. Will it be applicable for all the objects in the library?

Do i have some  single point of control (locking one object that applies to all its under lying objects)?

THanks dn regards,

Venkatesh.

[jhorber]

I see this is a large topic.

If you need a data protection at object level, check if immutability locks can help you.

Immutability locks are different from concurrency locks.

This requires some expertise.

The MetaClass should be set as subMetaClass of 'Lockable Object'.

For a specific object (object level), an immutability lock can be set using API code.

A specific menu can trigger this API code. This menu could be allowed only to authorized users.

As long as this object is locked, other users cannot update it.

Authorized users also need to be able to unlock objects: this will enables them to update the definition of the objects and lock them again after update.

See basic indications here:

http://community.mega.com/t5/custom/page/page-id/mega-kb-solution?sid=501D00000012bxuIAA

[ColruytTeam]

Hi Jerome,

The writing access area(which is given in person level) and the data access rules (Which is given in meta data level) will not work for out requirement.

We already implemented admin writing access area to all the objects in the specified library. For say Reference Library.

We actually have multiple libraries, in which, one library's (with all admin WAA data) data has to be protected.

The normal users should have read acccess to it and also creating the duplicate of the existing object in to another library.

The key users should have read-write access to it, and the new objects created by key-users in that library should also have the writing acces area as admin.

For that we have given normal users WAA as designer and key-users as Admin in user level. This leaded to another conflict. The objects created by key-users in another libraries also getting WAA as admin (which other users can not use them).

For that we've created separate user like FunctionalAdmin and who ever wants to change that library will login thru this user.

But this user will not be maintainable across many users in the system(no track for modifications). So we wanted a role which should have read-write access to that library. and can be assignable to many users.

Is data protection in Object level (not in meta data level) is possible? If so, please guide me how it is possible.

Thanks and regards,

[jhorber]

Hello Colruyt Team

This leads to a more general topic: the protection of shared objects

To protect an object you can consider several options.
You need to evaluate and choose one, then configure/implement it for your project needs.

Here are indications

• Use writing access area: they are not mapped to profiles but are quite easy to implements
  See http://community.mega.com/mega/attachments/mega/HOPEXV1R2/11/196/MEGA%20Administration%20-%20Supervi... section 'MANAGING DATA WRITING ACCESS'
• Use data access rules: they can be mapped to profile
  See http://community.mega.com/mega/attachments/mega/HOPEXV1R2/11/196/MEGA%20Administration%20-%20Supervi... section 'Managing Data Access Dynamically'
• Use locks (immutability)
  See an example of use in http://community.mega.com/mega/attachments/mega/HOPEXV1R2/11/197/MEGA%20Common%20Features%20EN.pdf, 'Managing Locks on Parent Objects'