[
https://jira.duraspace.org/browse/DS-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18885#action_18885
]
Robin Taylor commented on DS-819:
---------------------------------
Hi Joseph,
Seems there is a lot of interest in this area at the moment. Personally I've
been trying to figure out the best way to go without stretching the design of
DSpace too much. This is what I am thinking at the moment...
1. Make DCValue a DSpaceObject (leaving aside for the moment whether it should
actually be MetadataValue rather than DCValue). DSpaceObjects are hierarchical
in that they have parent objects, so, this would allow us make use of the
existing community/collection admin feature. If a user had admin authority for
a collection then that should extend to the metadata for the items in that
collection.
2. Replace the existing crude check on the user being an administrator in
MetadataExposure with a call to AuthorizeManager that already has the
functionality for community/collection admins.
3. Replace the current dspace.cfg coding with something more sophisticated.
DSpace already has functionality to do this in the form of ResourcePolicies.
Basically for each DSpaceObject you can define who has permissions for what
actions (READ, WRITE, etc), but as Claudia has pointed out elsewhere this may
not scale for every metadata value. Her suggestion is that we we would store
the 'isHidden' flag alongside each metadata term definition in the
metadataRegistry database table, seems like a good pragmatic solution at first
glance.
So I guess the main question for you are whether making use of the existing
community/collection admin feature would be fine grained enough to satisfy your
needs. Also, do you think that adding a 'isHidden' field to the
metadataregistry table matches your idea of 'masks'
Thats just a bit of a quick brain dump. I'll hopefully have more time to look
at this soon. We can continue this conversation here or on the other related
Jira tickets and hopefully tease out a solution suitable for all.
Cheers, Robin.
> Metadata Masking
> ----------------
>
> Key: DS-819
> URL: https://jira.duraspace.org/browse/DS-819
> Project: DSpace
> Issue Type: New Feature
> Components: DSpace API
> Reporter: Joseph Rhoads
>
> Dear Dspace community,
> I'm working on a project that needs to have different layers of access to
> metadata fields. (ie. Only certain people/groups should have access to
> certain metadata fields). I'm wondering if any in the dspace community have
> any ideas or experiences with this sort of thing? I'm gonna throw out some
> ideas to see if anyone is interested.
> I know that there are currently a couple of options related to items access,
> + You can let anonymous users view some info in the search/browse results
> + Then approved users/groups can have full-item read access (minus fields
> that are designated for administrators)
> + Administrators can see all fields (including those designated
> metadata.hide..... in the dspace.cfg file.)
> What I'm thinking about includes the following:
> + Adding the ability to create masks or streams of masks that can be applied
> at the community or collection level, and to specific groups.
> + Each mask would simply be a set of (metadata key, boolean value) pairs
> + I think collection administrators should be able to edit the masks though
> the web interface
> + And that the OAI indexing should be viewed as another group or person for
> this purpose.
> I have some questions:
> + Should the mask be on the display end(post SQL request) or the request
> end(pre SQL request)?
> + Presumably these masks would be persistent, where should they be stored?
> This topic is related to the following JIRA issues
> https://jira.duraspace.org/browse/DS-800
> https://jira.duraspace.org/browse/DS-716
> https://jira.duraspace.org/browse/DS-655
--
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
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
