[
https://jira.duraspace.org/browse/DS-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18889#action_18889
]
Joseph Rhoads commented on DS-819:
----------------------------------
Hi Robin,
I agree, there seems to be quite a bit of interest in and around this topic.
It seams like most of the pieces are there; that they just have to be
rearranged and with a better interface.
I entirely agree with point 2, AuthorizeManager should be used to see if a
person is a community/collection administrator in MetadataExposure.
Adding a 'isHidden' tag in the metadata registry would be a form of masking,
but that it's a bit more course-grained than I was thinking. That would be an
Archive-wide designation, much like the current system, whereas I'm looking at
more of a group-level designation. I think it would be more useful at the
group level.
I'm not sure that DCValue_s necessarily need to know who their parents are.
When items are accessed (and their metadata), you can get the Item's containing
collections and their parentObject. For this purpose it might be overkill but
there might be other reasons that a DCValue might want to inherit from
DSpaceObject. (I admit that I'm a little intimidated by the number of places
DCValue is used, and that adds to my reluctance to mess with it, but again,
there could be very good reasons for doing so.)
I've been thinking about the following:
1. Extend the MetadataExposure class in the following way, add another layer
to the Hashmaps that would represent the MaskID.
MetadataExposure contains two hashmaps
private static Map<String,Set<String>> hiddenElementSets
private static Map<String,Map<String,Set<String>>>
hiddenElementMaps
They hide schema.element, and schema.element.qualifier entries
respectively.
I suggest we extend it in the following way
private static Map<Integer, String,Set<String>> hiddenElementSets
private static Map<Integer, String,Map<String,Set<String>>>
hiddenElementMaps
This would allow another layer for MaskID, schema.element, and
schema.element.qualifier entries if they were part of a given mask.
The MaskID would be obtained by a lookup (possibly another hashmap)
based upon the User's group affiliations and the current collection_ID.
(Obtained from the item immediately before the call to 'isHidden' in those
three files???)
That's the least invasive way I see it right now. I admit that my brain may
be stuck on the first approach I thought of, so I'm very much interested in
keeping the conversation going.
What do you think?
-Joseph
> 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
