How to disable a document library easily?

[ahmedsyscs]

Hello,

A client of ours has chosen to allocate one site in Share per organizational department. For example, the Finance department has their own site. The IT department has their own site. And so on for the other departments (actually many other organizational units, but I'm simplifying on purpose).

The challenge we are facing arises when departments merge or split, and since the client's organization is very large (many thousands of employees), this scenario does happen on a regular, although infrequent, basis.

When a department is merged or split, we need a way to "disable" their existing site as we sort out the migration of content. By disable, we mean freeze the entire document library so that content cannot be added, deleted, or modified… a "read only" mode, you might say. Other aspects of the site (forums, blogs, wikis, etc.) are not relevant to us at the moment.

Is there a SIMPLE way to do this programmatically (via an API) or via the user interface? We already have a solution where we programmatically descend into the document library and recursively alter the permissions of all folders, subfolders, and documents. However, we were wondering if there is an easier way.

(I should add that there are cases where the endusers have purposely removed "Inherit permissions" from subfolders, so that they can have private folders. For this reason we cannot apply a change to the root folder and expect that change to trickle down always.)

Thanks in advance.

[scouil]

Hi,

One problem with your approach might be that whatever permissions you set on documents, the owner of that document will still have full rights on it.
Another lead (I didn't experiment with it, hence the term "lead") might be to expose the cm:lockable aspect (through share config).
Then you could create a simple recursive rule adding this aspect recursively and trigger it manually.

I haven't played around with the lockable aspect so it might not have the expected behaviour but it's worth a try.
You could potentially reach your goal while keeping the ACLs in place to be migrated as well (and no private folder suddenly becoming public once migrated)

[ahmedsyscs]

Thanks for the reply. We hit upon this solution as well. Locking the content was better than the original approach we considered.

Thanks again; we thought alike.