Security inheritance is applicable to only folders and tabs. When security is set to Inherit for a folder or tab, the refile process sets the same security on the subfolders and all the versions of documents within those folders and tabs. In cases where a user sets a folder's default security to an explicit value (Public, Private or View), refile assumes that the user intends to manage its security manually. Refile skips processing folders when inheritance is broken. By default, any changes you make to the security of a folder or tab during a refile are inherited by subfolders and documents in that folder or tab.
This section explains some of the common use cases you come across in iManage Work system and the possible proposals by refile.
Security Refile Use Cases
This section explains some of the common use cases you come across in iManage Work system and the possible proposals by refile.
Changing default security of a container
The following example explains the results of a proposed change to a folder's default security on subordinate items within and below that container.
In this example, a security refile event is triggered by changing the default security of a parent folder to Public. As the change is propagated down to the children items, one document (case 1) that has its default security set to Public. This document's default security is not changed because the two settings (the proposed default security and the document's current default security) is the same, and one of refile rules is never to change identical settings. However, if the document's default security setting is View (case 5), its default security is updated to Public.
Case | Refile's Proposed | Document's Current | Expected | Rule Matched |
|---|---|---|---|---|
1 | Default security is Public | Default security is Public. | No change. | Items with identical default security are not refiled for security. |
2 | Default security is Public | Document is Restricted. | No change. | Items marked as Restricted are not refiled for security. |
3 | Default security is Public | Document is Secured and Refile Secured Document is No | No change. | Secured Document |
4 | Default security is Public | Document is Secured and Refile Secured Document is Yes | Default security changes to Public. | Secured Document |
5 | Default security is Public | Default security is View. | Default security changes to Public. | Update Allowed. |
6 | Default security is Private | Default security is Public. | Default security changes to Private. | Update Allowed. |
7 | Default security is Private | Document is Restricted. | No change. | Items marked as Restricted are not refiled for security. |
8 | Default security is Private | Document is Secured and Refile Secured Document is set to No | No change. | Secured Document |
9 | Default security is Private | Document is Secured and Refile Secured Document is Yes | Default security changes to Private. | Update Allowed. Secured Document |
10 | Default security is Private | Default security is View. | Default security becomes Private. | Update Allowed. |
11 | Default security is View | Default security is Public. | Default security becomes View. | Update Allowed. |
12 | Default security is View | Document is Restricted. | No change. | Items marked as Restricted are not refiled for security. |
13 | Default security is View | Document is Secured and Refile Secured Document is set to No | No change. | Secured Document |
14 | Default security is View | Document is Secured and Refile Secured Document is set to Yes | Default security becomes View. | Update Allowed. Secured Document |
15 | Default security is View | Default security is View. | No change. | Items with identical default security are not refiled for security. |
Adding a user to a container
The table explains the results of a proposed change of adding a user to a workspace or folder.
In this example, a security refile event is triggered by adding user ACASE to getting Read/Write access. As the change is propagated down to the children items, one document (case 1) currently has its default security set to Restricted. The document's default security does not change because a document with a default security of Restricted never gets changed.
Case | Refile's Proposed | Document's Current | Expected | Rule Matched |
|---|---|---|---|---|
1 | User ACASE gets Read/Write access | Document is Restricted. | No change. | Items marked as Restricted are not refiled for security. |
2 | User ACASE gets Read/Write access | Document is Secured and Refile Secured Document is set to No | No change. | Secured Document. |
3 | User ACASE gets Read/Write access | Document is Secured and Refile Secured Document is set to Yes | User ACASE is assigned Read/Write access. | Update Allowed. Secured Document. |
4 | User ACASE gets No Access | Document is neither Restricted nor Secured. | User ACASE is assigned No Access, and cannot access the containers or items in those containers. | Update Allowed. |
Changing a user’s access level
The following example explains the results of a proposed change on modifying the access level of an existing user of a workspace or folder.
In this example, a document (case 3) is currently neither restricted nor secured and the user ACASE has No Access assigned to its parent container. A security refile event is triggered by changing ACASE's access to get Full Access to the parent container. As the change propagates down to its children, the document does not change and ACASE is not granted with Full Access to the document. This is because a Refile rule states that a user with explicitly assigned as No Access never changes.
Case | Refile's Proposed | Document's Current | Expected | Rule Matched |
|---|---|---|---|---|
1a | User ACASE gets Read/Write Access | Document is Secured and Refile Secured Document is set to No | No change. | Secured document. |
1b | User ACASE gets Read/Write Access | Document is Secured and Refile Secured Document is set to Yes | ACASE's access on the document is overwritten with Read/Write access. | Update allowed. See Secured Document rule. |
2 | User ACASE gets No Access | Document is neither restricted nor secured, and ACASE has explicit access. | ACASE's access on the document is overwritten with No Access. | Update allowed. |
3 | User ACASE gets Full Access | Document is neither restricted nor secured, and ACASE has explicit No Access on the document. | No change. | Users with No Access never have their explicit access level changed by a security refile. To change a user from No Access you must take extra steps. See No Access level never elevated rule in Refile rules |
4 | User ACASE gets Full Access | Document is neither restricted nor secured, and ACASE has explicit access. | ACASE's access on the document is overwritten with Full Access. | Update allowed. |
Removing a user from a container
The following example explains the results of a proposed change on removing an existing user from a workspace or folder.
In this example, a refile security proposal is made to remove a user from a container with a default security of Public (Case 2). The user is removed because no other refile rule prohibits that change.
Case | Refile's Proposed | Document's Current | Expected | Rule Matched |
|---|---|---|---|---|
1a | User ACASE is removed. | Document is Secured with user ACASE having Read/Write and Refile Secured Document is No | No change. | Secured Document. |
1b | User ACASE is removed. | Document is Secured with user ACASE having Read/Write and Refile Secured Document is Yes | User ACASE is removed. | Update allowed. See Secured Document. |
2 | User ACASE is removed. | Document is neither restricted nor secured, and user ACASE has No Access. | User ACASE is removed. Note that user ACASE can edit documents because the default security is Public and user ACASE has no additional restrictions. When refiling documents due to a security change, this is the only case a user with No Access changes. | Update Allowed. |
3 | User ACASE is removed. | Document is neither restricted nor secured, and user ACASE has Full Access. | User ACASE is removed. Note that user ACASE now has access based on the document's default security. Because the document is not restricted or secured, the default security can only be Public or View. | Update allowed. |
Moving a folder to a new location
The following example explains the results of a proposed change on moving a folder to a new location. The scenario illustrates the refile changes when a folder, along with its children (documents and folders), is moved directly to another folder, a workspace, whose default security is Public and has two explicitly assigned users.
When moving folders, the folder's default security setting is integral to determining whether a refile event occurs.
- If the folder's default security is set to Inherit, then refile service refiles subordinate items according to standard refile rules.
- If the folder's default security is not set to Inherit, the expectation is that folder owners want to manually maintain the folder security. Therefore, no refile event occurs after moving the folder. If the intention is for the folder to be refiled, its security must be changed to Inherit after the move from the new location.
For example, if a change is made by moving a folder and its contents (in this case documents and a folder) to a new folder location, the documents' default security attempts to match the new parent folder. In this example, the parent folder (a workspace folder) has a default security of Public and users KTHOMPSON and BDYSTRA both have Full Access.
Case | Item's Current State | Expected Result | Rule Matched |
|---|---|---|---|
Miscellaneous folder | Default security is set to Inherit. | No change. | (Not applicable) |
Document #123 | Default security is set to View. | Default security changes to Public, the following users are assigned: KTHOMPSON has Full Access BDYSTRA has Full Access JFALAT has access granted by the Public default security. FROTHGANGER and ACASE access reduces to read/write from Public default security. | Apply default security from new parent. The current default security and ACLs are deleted, then the new parent's default security ACLs are applied. This may possibly change some user's access level. See Container's default security set to Inherit in Refile rules |
Document #899 | Document is restricted. | No change. | Restricted items are not refiled. |
Document #1352 | Document is secured and Refile Secured Document is No | No change. | Secured Document. |
Document #1352 | Document is secured and Refile Secured Document is Yes | Default security is set to Public, the following users are assigned: KTHOMPSON has Full Access BDYSTRA has Full Access FROTHGANGER and ACASE access reduces to read/write from Public default security. | Update allowed. See Secured Document. |
Attorney Notes folder | Default security is not Inherit. | No change. | Items that do not Inherit security are not processed. |
Moving a document to a location that inherits security
The following case explains the results of a proposed change when a documents is move into a folder. This scenario illustrates where documents, and not the parent folder, are being moved directly to another folder whose default security is Inherit. That means, the folder is treated as if it had the default security of its parent, the workspace.
When moving documents to a new folder, the intention is to align the document security with the new folder's security. Restricted documents never change, and secured documents may change depending upon the Refile Secure Document setting.
For example, if a change is made by moving documents to a new folder location, the documents' default security attempts to match the new parent folder. In this example, the parent folder (a workspace folder) has a default security of Public and both the users KTHOMPSON and BDYSTRA have Full Access.
Case | Document's Current State | Expected Result | Rule Matched |
|---|---|---|---|
Document #123 | Document is neither restricted nor secured so it is refiled. | Document's default security changes to Public, and the following users are assigned: User KTHOMPSON has Full Access User BDYKSTRA has Full Access Additionally, ACASE and FROTHGANGER now drop from full access to Read/Write because they have been removed from the ACLs. JFALAT gains access since he is removed from the ACLs. All three users receive Read/Write access from the default security setting of Public. | Apply default security from new parent. The current default security and ACLs are deleted, then the container or document inherits the parent's default security and ACLs. This may possibly change some user's access level. See Container's default security set to Inherit in Refile rules. |
Document #899 | Document is Restricted. | No change. | Restricted items are not refiled. |
Document #1352 | Document is secured and Refile Secured Document is No | No change. | Secured document. |
Document #1352 | Document is secured and Refile Secured Document is Yes | Document's default security changes to Public, and the following users are assigned: User KTHOMPSON has Full Access User DYKSTRA has Full Access Additionally, ACASE and FROTHGANGER now drop from full access to Read/Write because they have been removed from the ACLs. They receive Read/Write access from the default security setting of Public. | Secured document. Update allowed. |
Moving documents to a new folder with explicit security
The following case explains the results of a proposed change to move documents into a folder. This scenario illustrates where documents, and not the parent folder, are being moved directly to another folder whose default security is Private (either as restricted, or, in this case, secured).
When moving documents to a folder that has explicit security, that is, where default security is set to Public, Private or View, document security is aligned to the parent folder. Restricted documents never change, and the secured documents may change depending upon the Refile Secure Document setting.
In this example, the parent folder has a default security of Private and users KTHOMPSON and BDYSTRA both have Full Access. A typical top down refile event, that is, where refile attempts to move from a parent folder to a child folder, stops at the first Private folder it encounters (the folder named Confidential Info) and does not attempt to perform a security refile on its contents. However, this case involves the documents being moved inside a folder so that those documents are involved in a security refile event. That event starts with the documents and not the parent folder, and attempts to inherent the parent's default security.
If the move involved a folder along with the documents, that folder is subject to refile rules.
Case | Document's Current State | Expected Result | Rule Matched |
|---|---|---|---|
Document #123 | Document is neither restricted nor secured so it is refiled. | Document's default security is set to Private, and the following users are assigned: KTHOMPSON has No Access BDYKSTRA has Full Access | Apply default security from new parent. The current default security and ACLs are deleted, then the container or document inherits the parent's default security and ACLs. This possibly changes some users' access level. See Container's default security set to Inherit in Refile rules. All users had their ACLs removed. Users KTHOMPSON and BDYKSTRA inherits ACLs from the parent. |
Document #899 | Document is restricted. | No change. | Restricted documents are not refiled. |
Document #1352 | Document is secured and Refile Secured Document is No | No change. | Secured Document. |
Document #1352 | Document is secured and Refile Secured Document is No | Document's default security changes to Private, and the following users are assigned: User KTHOMPSON has Full Access User DYKSTRA has Full Access Additionally, ACASE and FROTHGANGER now lose access because they are removed from the ACLs. | Secured Document. Update Allowed. |