[
https://jira.duraspace.org/browse/DS-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18627#action_18627
]
Tim Donohue commented on DS-655:
--------------------------------
This issue was
dhttps://jira.duraspace.org/secure/EditIssue!default.jspa?id=13933iscussed in
the DSpace Developers Mtg on Jan 12, 2011. Full text of discussion follows:
[20:10] <tdonohue> MetadataExposure hides fields except for System Admins -
this should extend to Community and Collection Admins :
https://jira.duraspace.org/browse/DS-655
[20:10] * mdiggory ([email protected]) has joined
#duraspace
[20:10] * PeterDietz adds that determining if the current user is a collection
admin is not as straight forward
[20:10] <mdiggory> HI everyone
[20:11] <tdonohue> hi mdiggory.. we're doing JIRA review, currently on:
https://jira.duraspace.org/browse/DS-655
[20:11] <mdiggory> catching up
[20:11] <PeterDietz> super admin == isAdmin().. collection admin ==
Group.isMember(context, collection.getAdministrators().getID())
[20:12] <tdonohue> Anyone have thoughts on DS-655, or volunteer to look into
this in more detail? It sounds like Bill Hays has a point, but I am not as
familiar with this area of the code
[20:13] <mdiggory> What she is asking for is authorization on metadata fields
[20:13] <mdiggory> so that specific fields can be hidden from specific users
[20:13] <mdiggory> pubic vs administrator
[20:14] <tdonohue> PeterDietz: Doesn't the AuthorizeManager.isAdmin(context,
DSpaceObject) method find a Community or Collection Admin?
[20:15] <mdiggory> PeterDietz: especially with the new delegation support
[20:15] <tdonohue> volunteers to investigate or add further comments to DS-655?
[20:16] <robint> tdonohue: I'll take it
[20:16] * hpottinger (80ce6c20@gateway/web/freenode/ip.128.206.108.32) has
joined #duraspace
[20:17] <tdonohue> ok, assign DS-655 to robint for investigation. Will revisit
later as necessary
[20:17] <mdiggory> TBH, theres already so much backwardness in the OAI
implementation... I wouldn't be worried about efficiency losses due to actually
attempting to authorize the content...
> MetadataExposure hides fields except for System Admins - this should extend
> to Community and Collection Admins
> --------------------------------------------------------------------------------------------------------------
>
> Key: DS-655
> URL: https://jira.duraspace.org/browse/DS-655
> Project: DSpace
> Issue Type: Improvement
> Components: DSpace API
> Affects Versions: 1.6.0, 1.6.1, 1.6.2
> Reporter: Bill Hays
> Assignee: Robin Taylor
> Original Estimate: 16 hours
> Remaining Estimate: 16 hours
>
> MetadataExposure provides an exclusion for SystemAdmins but not Community and
> Collection admins who are actually more likely to need access to metadata
> that is restricted to public view. For instance, the default metadata field
> for hiding is dc.description.provenance which is in the purview of Community
> and Collection admins at my location.
> Caveat: The comments in the class state that it is important to have a very
> efficient mechanism and to extend the class by calling
> AuthorizeManager.isAdmin(context, dso) would have a much greater overhead
> than the current AuthorizeManager.isAdmin(context). And for OAI this
> recommendation is not applicable.
> The hidden metadata is still available to all admins using the EditMetadata
> capability, yet this is a burden with the provenance field since it can be
> quite large.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
