I tend to think we would get further faster by refactoring the
existing system to meet our needs and the requirements outlined in the
Architectural review. I took a 20 minute analysis of the codebase and
determined the following
Tom,
I hadn't realized there was this duplication between policy and
collection tables. And its bitten us more than once in [EMAIL PROTECTED]
production, we currently have duplicate submitters and workflow
groups introduced in one revision where the default group names case
was changed all to caps.
Unfortunately, its still "very" entrenched in the codebase in 1.5.0
at this point. All the actual JSPUI and XMLUI Submission/Workflow
functionality depends on those fields It would be an ideal project
that could happen over 1.6 to 2.0 . It would appear, at first
blush, to be a case of database normalization and would afford us a
great enhancement to the system, namely that we could make the
administrative and submission workflow much much less "hardcoded".
.
It would involve:
Phase 1:
1.) Some update scripting to migrate any existing submitter groups/
workflow groups into resource policies if they are absent.
1.) removing those fields from the Collection table and calculating
the return values for Collection methods off the ResourcePolicy
table instead.
2.) deprecating those methods/attributes in the Collection java class.
Phase 2:
1.) Identify where in JSPUI and XMLUI the above methods are used.
2.) Establish a more flexible Workspace/Workflow API for managing
the Submission/Administration workflow where current hardcoded logic
is handled in external classes.
Phase 3:
1.) Migrate the JSPUI and XMLUI to use that workflow rather than
that embedded in the Collection, WorkspaceItem and WorkflowItem
classes.
2.) finally remove those methods/attributes in the Collection java
class.
the great thing is that this would finally separate Policy negotiation
from the objects themselves and we could consider where those policies
are stored in the future independent of the actual data model storage
and behavior. The work was already done on the AuthorizeManager
(probably should have been called PolicyManager :-)
Great observation.
Cheers,
Mark
On Feb 15, 2008, at 7:41 AM, Scott Phillips wrote:
The DSpace authorization system is showing it's age and has several
problems that have remained unaddressed. In my opinion the principle
problem is that it does not recognize the difference between a role
and a permission. Where a role is something like submitter, or
administrator, and owner while permissions are the basic edit, update,
delete primitives. If an eperson were granted the submitter role then
it would also imply a set of basic permissions over some resources.
This way the objects can check the primitive operations of access and
the interface can allow users to operate with the larger concept of
roles. What you are seeing is that that roles and permissions have
been half way mixed into something called a resourcepolicy - which
tries to be a permission system but has a some role concepts mixed in
as well.
We could go on and talk about how one would like to improve the
authorization system, but that's been discussed before. To answer
you're question these columns are still needed because that is where
DSpace determines who is allowed to submit or administrate a
collection, and yes those epersons must also be granted the basic
resource policies over those objects as well - so its best to avoid
situations where they are out of sync. We are way too far along in
this release to consider a database schema change of this magnitude.
Most everyone I've talk too agrees that the authorization system needs
to be re-designed from the group up, people complain about various
problems from how hard it is to use, it's implementation, and model.
However given all these complaints no one has ever taken the time to
create a patch to fix it which really shows that while it may be a
problem for users it's probably not that big of a problem.
If you would like to undertake a project working on the authorization
system for a future release I'm sure several developers would offer
their opinions on how to design a new system.
Scott--
On Feb 15, 2008, at 8:37 AM, Tom De Mulder wrote:
Could any of the more involved developers tell me why the database
schema
for DSpace 1.5 still has "admin" and "submitter" columns in the
collection
table, when there is a ResourcePolicy table? In our experience, if
the
former and latter disagree with each other, serious authz problems
occur;
it would be better if everything used the ResourcePolicy rather than
the
columns on the collection table.
Any reason why they can't be dropped for this release?
Best,
--
Tom De Mulder <[EMAIL PROTECTED]> - Cambridge University Computing
Service
+44 1223 3 31843 - New Museums Site, Pembroke Street, Cambridge CB2
3QH
-> 15/02/2008 : The Moon is Waxing Gibbous (58% of Full)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
DSpace-tech mailing list
DSpace-
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
