DSpace

Tracker: Patches

5 Authorization system: delegate admins - ID: 1373613

Last Update: Comment added ( bollini )

Details:

This patch makes a new Action available for any DSpace
object: bitstream, bundle, item, collection, community,
group.
The Action ADMIN allows any user to perform any other
action on the DSpace object and to set policies on the
object.
AuthorizeManager now checks permission to perform an
ADMIN action on DSpace object target when anyone tries
to set/create/remove a policy (this is more appropriate
than check for it with a "filter" on webUI).
A new implicit autorization mechanism is introduced by
the AuthorizeManager.isAdmin(Context,DSpaceObject)
method called by AuthorizeManager.authorize().

This mechanism throws the authorization check on the
"container" of the DSpace object.
The containers defined are:
- community: the parent community
- collection: the parent community
- item: the owner collection or the related collection
if the item is a "template"
- bundle: the item where the bundle resides
- bitstream: the bundle where the bitstream resides or,
if the bitstream is not inside any bundle, e.g. is a
logo, the related collection or community
- group: if the group is a workflow, submitter or admin
group the related collection (or community for the
admin group)
The implicit rule is performed on any "container"
object (e.g. bitstream - bundle - item - collection -
subcommunity - ........ - community - system) until a
permission is found or denied.
The COLLECTION_ADMIN action is now replaced by ADMIN
action on the collection.

For backwards compatibility, when new content
(subcommunity or collection) is created in a community,
by a user with only ADD permission, the
Community.createSubCommunity() and
Community.createCollection() methods automatically
create the admin group for this new content and insert
the current user in it.

WRITE permission on a community or collection now does
not allow the user to edit the related groups but only
to set the metadata. This is more refined than before,
because if needed, the system admin can authorize the
user to edit the group by creating a specific policy
(ADD/WRITE or ADMIN permission) - webUI authorize
system needs to be extended.

Submitted:

Andrea Bollini ( bollini ) - 2005-12-05 15:31

Priority:

Status:

Open

Resolution:

None

Assigned:

Nobody/Anonymous

Category:

None

Group:

None

Visibility:

Public

Comments ( 4 )

Date: 2006-04-26 09:29 Sender: bollini Logged In: YES user_id=1293299 Thank you for your comments&bugs fix this really help me to keep the patch update-to-date and live! After dspace 1.4 release I will work for the inclusion in DSpace core so any help is welcome
Date: 2006-04-19 18:16 Sender: tdonohue Logged In: YES user_id=1320825 Great patch! It's exactly what we were looking for (at UIUC, we were just struggling with the lack of a DSpace Community Administrator, etc). However, I've come across a few bugs in playing around with it. I've installed it on Dspace 1.3.2, but I'm fairly certain these bugs carry over to DSpace 1.4alpha (or whatever version you created the patch for). I'll try to describe them here (but contact me at tdonohue@uiuc.edu , if something doesn't make sense): Bug #1) In Collection.java, in the "createWorkflowGroup()" method, you have a: ourContext.setIgnoreAuthorization(false); followed by a: ourContext.setIgnoreAuthorization(true); You definitely don't want to keep "IgnoreAuthorization" set to true! I think you meant to have it set back to "false" directly after the "AuthorizeManager.addPolicy()" call in this method. Bug #2) Currently you get an "Authorization Error" (on creating a bundle) after accepting a License, when you Submit a new item to DSpace as a non-Admin user. This looks like it occurs because you need to do the following in Item.java: In Item.java, in the "addBundle()" method, you need to move this line to the END of the method: AuthorizeManager.inheritPolicies(ourContext, this, b); The reason is that this "inheritPolicies" will throw an AuthorizeException if it is called BEFORE you create the entry in the "item2bundle" table. This happens since "inheritPolicies" cannot tell you are an Item Admin until that item2bundle entry is in place! Beyond that, the patch looks to be working great. If I run across other errors, I'll let you know so that you can keep the patch up-to-date!
Date: 2005-12-15 09:37 Sender: bollini Logged In: YES user_id=1293299 This patch is full indipendent from the old one. It is based on a new concept of implicit inheritance of permissions. An "admin" of a dspace object (community, collection and any other) can manage any dspace objects in it without set (manually or automatically) specific Resource Policies
Date: 2005-12-14 21:22 Sender: rtansley Logged In: YES user_id=166234 Does this replace the previous "community administrator" patch? Does it depend on it? Or is it independent?

Attached File ( 1 )

Filename	Description	Download
patch_community_admin.txt	Patch for CVS Head at 2005-12-05 11:00 GMT	Download

Change ( 1 )

Field	Old Value	Date	By
File Added	158719: patch_community_admin.txt	2005-12-05 15:31	bollini

DSpace

Tracker: Patches

Comments ( 4 )

Attached File ( 1 )

Change ( 1 )

About SourceForge

Find Software

Develop Software

Community

Help