[
https://jira.duraspace.org/browse/DS-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18774#action_18774
]
Claudia Jürgen commented on DS-655:
-----------------------------------
Hi Robin,
there is a distinction between referring to MetadataField or MetadataValue
(better not use DCValue, it's deprecated).
1. Regulating visibility of a MetadataField and/or a MetadataSchema
This will affect all the MetadataValues of this type.
a) At the moment this is done based on the dspace.cfg option
metadata.hide.[schema].[element].[qualifier] = true
and
- eliminates the exposure via DSpace UI to non instance admins
- to external sources like OAI
The parameter itself is a bit awkward as setting it to false makes little
sense.
To clear the MetadataExposure confusion see [DS-780] one could change the
parameter to something like:
metadata. hide = [schema].[element], \
[schema].[element].[qualifier], \
[schema].[element].*
[schema].*
which only lists the restricted fields (wildcards possible).
This still does not distinct further, e.g. between instance admins and
delegated admins.
One could include kind of access levels there, like adding the role for which
it is visible instance-admin, community-admin, collection-admin.
But this would add to the allready overloaded dspace.cfg.
b) An alternative for regulating the access to fields and/or schemata would be
putting it in the db and make it managable along with the registries.
There one could use a simple visibility flag, like the internal one for the
bitstream formats. This would enable only 2 levels of visibility.
c) Make them DSpaceObjects and use resource policies, which might become a
unwieldy and most likely would not scale.
2. Regulating access to MetadataValue
Regulating the access to a MetadataValue will affect only one specific
metadata e.g. like one occurrence of dc.description in an item's metadata.
This can only be achieved on db level with resouces policies or a simple flag,
depending how granular a distinction is wanted
Imo 1b ( or just the changed configuration) would be a compromise it keeps the
approach simple and easy to manage. With regards to community and collection
admins, they can still see the data in the edit item mode, can't they?
In general extend the list of DSpaceObjects to include MetadataValues would be
essential to a lot of other developments like enabling metametadata a big + 1
for this.
Cheers
Claudia
> 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
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
