[
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
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
