On 2 May 2011 03:35, Richard Rodgers <rrodg...@mit.edu> wrote:
>
> The data model forces all items to belong to at least one container
> (collection) - this is why there is no public item.create() either (which
> would allow uncontained items in the repository).
> Items can also belong to other containers. Therefore the API requires that
> calling code (not just UI code, by the way) manipulate items though a
> collection.
>
And that's one of the worst parts of the data model. Sort of! Sure, it makes
a certain amount of sense that there has to be a container for any item that
is installed in the repository (although 'tagging' is probably better than
any fixed hierarchy) - but because a wrapped Item is used for submission, it
means that you can't simply submit something without a collection, to be
organized later - either automatically from the metadata, or manually by the
administrators / reviewers. This is often desired behaviour (as it takes
some of the barriers away from submitters). It can also become more
important with things like SWORD - let external systems submit 'blind' to a
repository, and let the librarians manage what happens with it.
> The authorization model distinguishes regular users (where policies are
> checked) and administrative 'super' users ( where they aren't).
> The assumption is that most calls are made by regular users of the system
> with limited powers. So how would item.delete() work for regular users?
> Suppose they had permissions on a linked collection of the item, but not
> on the owning collection. Would it fail completely, succeed in removing the
> item from collections the user was allowed to do, and leave the rest? The
> semantics (contract) of the method become a little more complicated.
> The only user that could be assured of success would be the super-user, and
> what is the use-case for an administrator deleting an individual item?
>
Actually, simplistically it could work itself out - you delete from all
collections (linked or owner), and if it any throw an authorization
exception the transaction rolls back and the exception is exposed.
The linked vs owning collection is interesting - of course, you can just
delete/remove from the linked collection if that's what you want. You
shouldn't delete an item in order to remove it from a collection.
There are a couple of reasons for making this a service rather than burying
it deep into the content model. The most important is that it further buries
the restrictions and assumptions of the content model within it - we should
want and be working towards more flexibility in that model. The second,
which is what you've covered, is that to deal with the rigidity of the model
you need to employ a strategy for interpreting the permissions - and
legitimately you can see different requirements in different repositories.
Hence, you would want that strategy outside of the content model where you
can easily swap the implementation.
But this is all fundamentally the problem of having a rigid model, and a lot
of assumptions to cope with interpreting simplistic permissions to keep the
model consistent / make it work. Editing or deleting/withdrawing items
should be determined solely by the permissions of the item (and you can
[selectively] add permissions for users / groups as you map items to
collections).
Removing an item from a collection is a distinct operation - it should not
be confused / overloaded with deleting items, it should only be determined
by permissions on the collection, and it should always be possible
regardless of ownership and mapping status. Yes, that means orphan items -
but we can always find ways of dealing with them (eg. event handler for
unmaaping collections - checks for orphan, sends admin email and withdraws
item).
G
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
