[Dspace-general] Delegate Admins & authorization system

[Fabio Batalha]

Ok, I found the script that creates the first admin user, but I'm getting
this error when I execute the  create-administrator



Exception in thread "main" java.lang.NoClassDefFoundError:
org.dspace.administer.CreateAdministrator
   at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0)
Caused by: java.lang.ClassNotFoundException:
org.dspace.administer.CreateAdministrator not found in
gnu.gcj.runtime.SystemClassLoader{....



----- Original Message ----- 
From: "Andrea Bollini" <bollini at cilea.it>
To: <dspace-general at mit.edu>
Sent: Monday, December 05, 2005 1:26 PM
Subject: [Dspace-general] Delegate Admins & authorization system


> Hi,
> I'm pleased to announce the release of a patch that modifies the
> authorization mechanism of DSpace. It introduces a useful implicit
> rule for permissions and also a simple realization of a community admin
role.
> The patch is for today's CVS Head (2005-12-05 11:00 GMT).
>
> 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.
>
> We have tested the patch for creation of new community, collection,
> submission, workflow and any other situation that we have thought of,
> but if anyone discovers any bugs please send me an email and I will
> be happy of working on it for allowing the inclusion of the patch in
> the DSpace core.
>
> Best regards,
> Andrea
>
> _______________________________________________
> Dspace-general mailing list
> Dspace-general at mit.edu
> http://mailman.mit.edu/mailman/listinfo/dspace-general