[ https://jira.duraspace.org/browse/DS-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18761#action_18761 ]
Robin Taylor commented on DS-655:
---------------------------------
There appear to be two relevant Java classes -
MetadataExposure - Checks to see if a metadata element has been flagged as 'hidden' in the dspace config and if so then doesn't display it unless the user is in the administrator group.
AuthorizeManager - Roughly speaking, checks to see if a user is authorised to perform a particular action on a resource.
I would argue that there is no need for MetadataExposure since AuthorizeManager could/should perform the same function, and it would be better design to only have one place to go to for any authorisation needs.
What development would need done to allow this ?
Firstly change DCValue to extend DSpaceObject so that it can be passed as a parameter to AuthorizeManager. Then there are a number of options...
1. Hack Authorizemanager to check on the type of the DSpaceObject and if it is a DCValue then look up dspace.cfg as MetadataExposure currently does.
Note :- by passing as a parameter to AuthorizeManager an Action that is only avail to Admins and community/collection admins we could satisy this Jira issue.
2. Same as 1 but get rid of the lookup of dspace.cfg by storing the 'isHidden' values in the metadata registry in the database. This is Claudia's request "https://jira.duraspace.org/browse/DS-800 - Manage visibilty of metadata fields as field attribute rather than in dspace.cfg".
3. Store Resource Policies for each DCValue. On the face of it this appears to be the best solution as it would allow for different levels of metadata visibility for item/collection/community/site, plus it would remove the need to consider DCValue objects differently with AuthorizeManager, but it would require a lot more development.
Realistically I would aim to do number 2. Any objections ?
Cheers, Robin.
> 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

[ 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 (~mdiggory@...) 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@.../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

[ https://jira.duraspace.org/browse/DS-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18761#action_18761 ]
Robin Taylor commented on DS-655:
---------------------------------
There appear to be two relevant Java classes -
MetadataExposure - Checks to see if a metadata element has been flagged as 'hidden' in the dspace config and if so then doesn't display it unless the user is in the administrator group.
AuthorizeManager - Roughly speaking, checks to see if a user is authorised to perform a particular action on a resource.
I would argue that there is no need for MetadataExposure since AuthorizeManager could/should perform the same function, and it would be better design to only have one place to go to for any authorisation needs.
What development would need done to allow this ?
Firstly change DCValue to extend DSpaceObject so that it can be passed as a parameter to AuthorizeManager. Then there are a number of options...
1. Hack Authorizemanager to check on the type of the DSpaceObject and if it is a DCValue then look up dspace.cfg as MetadataExposure currently does.
Note :- by passing as a parameter to AuthorizeManager an Action that is only avail to Admins and community/collection admins we could satisy this Jira issue.
2. Same as 1 but get rid of the lookup of dspace.cfg by storing the 'isHidden' values in the metadata registry in the database. This is Claudia's request "https://jira.duraspace.org/browse/DS-800 - Manage visibilty of metadata fields as field attribute rather than in dspace.cfg".
3. Store Resource Policies for each DCValue. On the face of it this appears to be the best solution as it would allow for different levels of metadata visibility for item/collection/community/site, plus it would remove the need to consider DCValue objects differently with AuthorizeManager, but it would require a lot more development.
Realistically I would aim to do number 2. Any objections ?
Cheers, Robin.
> 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

[ 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

[ https://jira.duraspace.org/browse/DS-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19032#action_19032 ]
Robin Taylor commented on DS-655:
---------------------------------
With regards to making either DCValue or MetadataValue a DspaceObject - Ideally we would choose MetadataValue since its viewed as a replacement for the deprecated DCValue, but MetadataValue is not used anywhere. Even Item only has methods that return DCValues rather than MetadataValues. Until such time as DCValue is truly replaced by MetadataValue throughout the code its not a viable option. So what about DCValue ? It doesn't have all the required methods to be a DSpaceObject eg. find(...). I could add these methods but its a deprecated Class. We need to resolve the DCValue vs MetadataValue issue before deciding which one should be a DSpaceObject.
> 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

[ https://jira.duraspace.org/browse/DS-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19041#action_19041 ]
Joseph Rhoads commented on DS-655:
----------------------------------
Not sure if this is the appropriate place, but I also think the issue of DCValue vs MetadataValue should be resolved. DCValue is depricated but right now it's all over the place in the codebase. MetadataValue is used much less often, but I think it's better coding.
> 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

[ https://jira.duraspace.org/browse/DS-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19042#action_19042 ]
Tim Donohue commented on DS-655:
--------------------------------
+1 to what Joseph Rhoads said. I think the "best way" forward is to properly integrate MetadataValue into the code, and get rid of DCValue (which we may want to separate into a different JIRA issue itself, as it's a semi-large task). Unfortunately, it seems no one ever got around to that in the past, and therefore DCValue is still throughout the code, despite being deprecated.
> 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

[ https://jira.duraspace.org/browse/DS-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19050#action_19050 ]
Bill Hays commented on DS-655:
------------------------------
I would respectfully disagree with the suggestions to remove DCValue and use MetadataField or MetadataValue in its place. I believe the use cases for a simple metadata element bean are distinct enough not to overlay database access classes with them. No doubt DCValue dates back to a time without multiple schemas and at the very least has the wrong name. I've used them all in code I've developed and have found DCValue, despite its deprecated status, to be necessary.
> 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