Edit permissions - Revision history

David: /* Scenario five: Add the ability to translate to a specified language */ close note

2013-07-10T17:26:22Z

Scenario five: Add the ability to translate to a specified language: close note

David: /* Scenario three: Add user to the contributor group as an alternative approach */ close note

2013-07-10T17:25:57Z

Scenario three: Add user to the contributor group as an alternative approach: close note

David: /* Scenario one: Allow the public to view and download master digital objects */ fix name of "Grant" button

2013-07-09T17:21:50Z

Scenario one: Allow the public to view and download master digital objects: fix name of "Grant" button

David: /* Scenario one: Allow the public to view and download master digital objects */ minor changes to text

2013-07-09T17:21:14Z

Scenario one: Allow the public to view and download master digital objects: minor changes to text

David: /* Scenario one: Allow the public to view and download master digital objects */ minor changes to text

2013-07-09T17:16:17Z

Scenario one: Allow the public to view and download master digital objects: minor changes to text

David: /* Scenario one: Allow the public to view and download master digital objects */ Use numbered list for instructions

2013-07-09T17:14:55Z

Scenario one: Allow the public to view and download master digital objects: Use numbered list for instructions

David: Add screenshot for /* Scenario one: Allow the public to view and download master digital objects */

2013-07-09T17:13:28Z

Add screenshot for Scenario one: Allow the public to view and download master digital objects

David: Add /* Scenario one: Allow the public to view and download master digital objects */

2013-07-09T17:05:15Z

Add Scenario one: Allow the public to view and download master digital objects

Jessica: /* Scenario one: In a multi-repository system, add a user who can create, update, edit, delete and publish archival descriptions belonging to one archival institution only (or whatever preferences the Administrator wants to set for the User) */

2012-05-11T17:07:14Z

Scenario one: In a multi-repository system, add a user who can create, update, edit, delete and publish archival descriptions belonging to one archival institution only (or whatever preferences the Administrator wants to set for the User)

Evelyn at 00:08, 21 February 2012

2012-02-21T00:08:49Z

@@ Line 90: / Line 90: @@
 * Make the user a translator by adding them to the translator group (the same way that you added a user to the contributor group). This means that they will be able to translate to any language.
 * Instead of making the user a translator, which would allow them to translate to any language, add a language to which a user can translate. This means that they will be able to translate only to the specified language, and only those archival descriptions and authority records they are allowed to update. In this scenario, we will add the ability of the user to translate to Dutch.
 Go to admin > users > "UserName". You should be in looking at the View user profile screen; if not, click Profile (to the left of Archival description permissions). Click Edit, then click on the blue "Access control" link. In allowed languages for translation, select Dutch. Click Save. The user will now be able to translate from any source language to Dutch. Note that the list of languages is derived from the languages added in the settings menu. See [[add/remove languages]]. Note also that you can add more languages from this list as needed.

← Older revision		Revision as of 17:25, 10 July 2013
Line 56:		Line 56:

	When refining user permissions, it is often useful to start with the group to which the user belongs. You can refine permissions for the group, then add users to the group, all of whom will inherit the modified permissions. Any permission that has not been "granted" by the current group (e.g., contributor, editor) or its parent group (authenticated) is considered "denied" by default. In other words the default for the system is to deny permission unless a rule explicitly grants it.		When refining user permissions, it is often useful to start with the group to which the user belongs. You can refine permissions for the group, then add users to the group, all of whom will inherit the modified permissions. Any permission that has not been "granted" by the current group (e.g., contributor, editor) or its parent group (authenticated) is considered "denied" by default. In other words the default for the system is to deny permission unless a rule explicitly grants it.
		+
		+	</div>

	In the main menu bar, go to admin > groups > contributor. Click on Archival description permissions in the grey menu above the title bar. Your screen will show the default "Grant" permissions for the contributor group - i.e. it shows you everything the user is permitted to do. The contributor group inherits some of its settings from its parent group, authenticated (which is all users who have successfully logged-in).		In the main menu bar, go to admin > groups > contributor. Click on Archival description permissions in the grey menu above the title bar. Your screen will show the default "Grant" permissions for the contributor group - i.e. it shows you everything the user is permitted to do. The contributor group inherits some of its settings from its parent group, authenticated (which is all users who have successfully logged-in).

@@ Line 21: / Line 21: @@
 # Click the "Archival description permissions" tab
 # Click "Edit"
-# Under ''All Archival description > Access master'' click the "Allow" toggle
+# Under ''All Archival description > Access master'' click the "Grant" radio button
 # Click "Save"

@@ Line 21: / Line 21: @@
 # Click the "Archival description permissions" tab
 # Click "Edit"
-# Under ''All archival descriptions'' next to Access master click "Allow"
+# Under ''All Archival description > Access master'' click the "Allow" toggle
 # Click "Save"

@@ Line 18: / Line 18: @@
 This will allow the public to view or download the master objects in addition to viewing the thumbnail and reference display copies of digital objects.
-# Click admin > groups > anonymous.
+# Click Admin > Groups > Anonymous in the administrator's menu
-# Click the "Archival description permissions" tab.
+# Click the "Archival description permissions" tab
-# Click Edit
+# Click "Edit"
-# Under ''All archival descriptions'' next to Access master click "Allow".
+# Under ''All archival descriptions'' next to Access master click "Allow"
-# Save the record.
+# Click "Save"
 <br style="clear:both" />

@@ Line 16: / Line 16: @@
 [[Image:Allow access to master representation.png|300px|right|thumb|Fig.3 View permissions by repository.]]
-Go to admin > groups > anonymous. Click on Archival description permissions. Click Edit. Under ''All archival descriptions'' next to Access master click "Allow". Save the record. This will allow the public to view or download the master objects in addition to viewing the thumbnail and reference display copies of digital objects.
+This will allow the public to view or download the master objects in addition to viewing the thumbnail and reference display copies of digital objects.
 <br style="clear:both" />

@@ Line 6: / Line 6: @@
 </div>
-== Scenario one: In a multi-repository system, add a user who can create, update, edit, delete and publish archival descriptions belonging to one archival institution only (or whatever preferences the Administrator wants to set for the User) ==
+<div class="note">
 <div class=clear fix>
 <ol>
@@ Line 32: / Line 41: @@
 </div>
-== Scenario two: Add user to the contributor group as an alternative approach ==
+== Scenario three: Add user to the contributor group as an alternative approach ==
 <div class="note">
@@ Line 55: / Line 64: @@
 </div>
-== Scenario three: Remove the ability to create and update authority records ==
+== Scenario four: Remove the ability to create and update authority records ==
 </div class="note">
 Permissions for authority records can be refined in some of the same ways they can be refined for archival descriptions. In a multi-repository setting it may be desirable to prevent users from creating and/or updating authority records, because one authority record may be linked to archival descriptions belonging to more than one archival institution.
@@ Line 62: / Line 71: @@
 </div>
-== Scenario four: Add the ability to translate to a specified language ==
+== Scenario five: Add the ability to translate to a specified language ==
 <div class="note">
@@ Line 73: / Line 82: @@
 </div>
-== Scenario five: Remove the ability to view and download master digital objects ==
+== Scenario six: Remove the ability to view and download master digital objects ==
 <div class="note">
@@ Line 83: / Line 92: @@
 Go to admin > users > "UserName". Click on Archival description permissions. Click Edit. Under ''All archival descriptions'' next to Access master click Deny. Save the record. This will allow the user to view thumbnail and reference display copies of digital objects, but not to view or download the master objects. Note that if you do not wish to have any users belonging to the Contributor group viewing or downloading masters digital objects, deny permission for this activity at the level of the group - i.e. go to admin > groups > contributor and make the change at that level instead of the level of the individual user.
-== Scenario six: Add ability to create, update, and delete subject terms ==
+== Scenario seven: Add ability to create, update, and delete subject terms ==
 <div class="note">

@@ Line 19: / Line 19: @@
 <br style="clear:both" />
 [[Image:singlerep_user03.png|300px|right|thumb|Fig.3 View permissions by repository.]]
-<li>Click Edit. Select Permissions by Repository and click Add Repository. Select Repository name from list. Click on Submit.(See fig.3)</li>
+<li>Select information object permissions. Click Edit. Select Permissions by Repository and click Add Repository. Select Repository name from list. Click on Submit.(See fig.3)</li>
 <br style="clear:both" />
 [[Image:singlerep_user04.png|300px|right|thumb|Fig.4]]

@@ Line 14: / Line 14: @@
 <li> When refining user permissions you can begin by creating a User, but do not assign them to a unique User group. Leave this blank and it will automatically assign the User to the parent group of authenticated (which is all users who have successfully logged-in)(See fig.1)</li>
 <br style="clear:both" />
-[[Image:singlerep_user02.png|400px|right|thumb|Fig.2.View User permissions screen]]
+[[Image:singlerep_user02.png|300px|right|thumb|Fig.2.View User permissions screen]]
 <li>
 In order to restrict permissions to descriptions of a particular institution, we need to go to Admin menu > Users. Select the User you want to restrict to specific repository permissions.(See fig.2)</li>