[ https://jira.duraspace.org/browse/DS-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19127#action_19127 ]
Brian Freels-Stendel commented on DS-824:
-----------------------------------------
Hi Andrea.
I think it would be possible (and perhaps desirable) to work as closely to the regular functioning of the system as possible. That might mean putting a line in the resourcepolicy table. I'm a little worried, though, about what that means for the group (or individual, although I think eperson policies aren't supported yet) that would be specified. I think it would require a real group.
My initial thoughts were since this will require a new table anyway (unless only people with accounts could request access to items, storage of names/e-mails would be necessary), I was thinking it could hold dates to specify start/end of access privs. (So far, I've come up with these columns for that table: name, e-mail, requestor_notes, author_notes, date_initiated, date_answered, date_end_access, request_denied, request_key.) That would take care of where to store the relevant dates. Ideally, we'd want to allow admins access to the information, and keeping it in a separate table would be the easiest way to access it. On the other hand, it would be next to impossible to include it in other stuff, such as the policy tool.
After that, though, I was thinking that the process in the IP authentication with special groups might be a model to extend. It goes so far as to 'ghost' users into a group (an instantiated group, granted.) That sort of thing might be able to be extended into the ghosting of a non-existent group, which could be fed into the regular authorization system. (It would be possible to use the resourcepolicy table as well, inserting the ghost group into the information returned; but it seems like it might be difficult to specify the criteria to extract the particular rule.) I'm worried, though, that this might be a trick that isn't acceptable. Is it an end-run around security that could be used nefariously? Or can it be implemented securely, so there's no need to worry about it?
As you can see, I'm still struggling with philosophical issues as much as programmatic ones, so I appreciate all the input I can get.
> Request Copy function for XMLUI; would allow author of item to give viewing privs to restricted item
> ----------------------------------------------------------------------------------------------------
>
> Key: DS-824
> URL: https://jira.duraspace.org/browse/DS-824
> Project: DSpace
> Issue Type: New Feature
> Components: Documentation, Language Packs, XMLUI
> Reporter: Brian Freels-Stendel
> Priority: Trivial
>
> The University of Minho developed a patch that gives this functionality in JSPUI: https://wiki.duraspace.org/display/DSPACE/RequestCopy .
> In implementing it for the XMLUI, I would like to alter the functionality so that the process looks something like:
> a. User clicks on restricted item link
> b. System responds with current behavior, adding a link/button to request privs to view item
> c. Clicking link to request privs to view item sends e-mail to author of item: includes Yes or No options
> d. Clicking yes sends e-mail to User with link to view item
> e. Clicking on link creates 'ghost' group with read access to item, including associated bitstreams. (Probably time-limited; one month?)
> This process would improve on the original process of sending the bitstreams to the User via e-mail; large documents often exceed outgoing mail limits, or incoming mailbox size restrictions. However, it also presents possible problems in trying to bypass the authorization system.
> I'm just starting to trace paths into the guts of XMLUI, so the general process is still in flux. I'd welcome any input, particularly regarding how to temporarily grant viewing privs to the restricted bitstreams.
--
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
|