Reader domain author domain

Reader domain:

If you want to restrict access to a specific document created by a form, add a "Reader" field to the form. The "Reader" field clearly lists users who can read the documents created in this form. For example, if you restrict the personnel files of an employee to only members of the "Human Resources" department, the employee himself or herself, and the employee's manager, they can be listed in the "Reader" domain. Users who do not have the "Reader" permission on the document cannot view the document in the view. If there is an access list in the form, the name in the "Reader" field will be added to the access list of the Form. Otherwise, the reader field controls the access to the documents created from this form.

The input items in the "Reader" field cannot grant users higher access permissions than those specified in the database access control list (ACL), but can only further restrict access permissions. Users who are specified as "inaccessible" in the database cannot read the documents in the database even if they are included in the "Reader" domain. On the other hand, users with "editors" (or higher) Access Level in the access control list cannot read documents if they are not included in the "Reader" domain.

In the following cases, users with "editors" (or higher) access level for the database can edit the document: 1. these users are listed in the form's read/access list, "Reader" domain, or "author" domain.

2. There is no read access list restriction for forms, and there is no "Reader" or "author" domain.

The reader domain is the only domain that can determine who can read this document. No matter what permission, as long as it is not in the reader domain, it is not authorized to read this document. (a document can have multiple reader domains)

Author domain:

The "author" domain works collaboratively with the "author" Access Level in the database access control list. If you specify a user in the access control list that has an "author" access level, you can read the documents in the database, but cannot edit the files, even their own files. Adding users to the "author" Domain allows them to edit their own documents, thus extending their access permissions.

Projects in the author domain cannot go beyond the database access control list, but can only be refined. Users who are specified as "accessors" in the database cannot edit documents even if they are included in the "author" domain. Users with Database "editors" (or higher) access level are not affected by the "author" domain. The "author" domain only affects users with "author" Access Level in the database.

Note that you must enter a full level name in the author domain, for example, John Smith/Acme/West, rather than a simplified common name.

The author domain is only useful to users who have the author permission in the database ACL. The unique purpose of setting the author domain is: allow users with author permissions in the database to edit documents (because by default, users with author permissions cannot edit documents)

If the user is in the author domain, but not in the reader domain, the user can read this document. This should be: reader domain = reader domain + author domain.

Users in the author domain of the reader domain can use @ name ([CN]; @ username) without the organization name.

If the database is to be used on the Internet, the author permission is generally granted to anonymous. At this time, the user has the right to open a form and create a document. However, anonymous cannot edit or delete a document, in this way, you can ensure the security of documents in the database, and enable Anonymous to run the proxy, open the form, and publish articles.

 

From http://hi.baidu.com/ghostresur/blog/item/9b4d9f505d9f2c5f1138c2e0.html