[ 
https://jira.duraspace.org/browse/DS-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25023#comment-25023
 ] 

Tim Donohue commented on DS-1046:
---------------------------------

Discussed in the DSpace Developers meeting yesterday (June 6, 2012).  
Essentially, we agree this sounds like a good option. Mostly we need to locate 
a volunteer to look into implementation details.  A bit more info in the 
discussion pasted below:

[20:11] <tdonohue> next up, DS-1046
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-1046 ] - [#DS-1046] 
Add metadata export for community and collection managers - DuraSpace JIRA
...
[20:13] <mhwood> 1046 looks like yet another special case of We Need 
Finer-Grained Permissions.
...
[20:15] <tdonohue> It sounds like 1046 may just require enabling the metadata 
export link for comm/coll admins? That seems like it might not be that hard 
(unless I'm overlooking something)
[20:17] <mhwood> That would work, I think. But we keep having requests like 
this all over, and if we can ever get around to reworking the permissions then 
they all go away -- you just set your permissions properly and people get what 
they are supposed to have.
[20:18] <mhwood> So, for a quick fix, yes, just wire that permission into the 
code. But there's a more general fix, which I try to bug us all about at 
suitable intervals....
[20:19] * hpottinger thinks this would be a good use of a business rules 
engine...
[20:20] <mhwood> Yup, but it starts with staring at the data model and writing 
out a list of what could and should have separate permissions.
[20:20] <tdonohue> one of the oddities about the "Export Metadata" 
functionality is that it's actually only available when visiting a community or 
collection page (then it's in the XMLUI Context menu). It seems odd then that 
only a full SysAdmin can use it. Usually the SysAdmin tools are under "XMLUI 
Administrative" menu
[20:20] <mhwood> Point.
[20:21] * mdiggory (~mdigg...@rrcs-74-87-47-114.west.biz.rr.com) has joined 
#duraspace
[20:21] <tdonohue> But, on the flip-side, the "Import Metadata" option is in 
the XMLUI Administrative menu (which *is* SysAdmin specific). So, all in all, 
this is slightly odd
[20:22] <mhwood> Yes, it should be made less odd.
[20:22] <mdiggory> Hi everyone, sorry I'm late :-)
[20:24] <tdonohue> So, for Ds-1046, I'd be OK with giving Community/Collection 
Admins ability to export metadata. But, it does then seem slightly odd that 
they cannot import it again -- but as that's the more dangerous task, perhaps 
that's OK
[20:24] <mhwood> Not odd that read/write permissions are different, but that 
they are in two such different places.
[20:25] <mdiggory> Seems like a job for delegated administration to determine
[20:25] <mhwood> Hence my usual rant about finer-grained permissions.
[20:25] <tdonohue> I'm assuming this must not be covered by the delegated admin 
tools that are already available
[20:26] <helix84> just a comment - i often give different people the csv with 
metadata to edit, but i'm the only one who ever does the import, and I always 
look at the diff. so this is definitely a valid use case.
[20:27] <tdonohue> maybe we just need a few new delegated admin configs: 
'core.authorization.collection-admin.export-metadata = true/false' and 
'core.authorization.community-admin.export-metadata = true/false'
[20:28] <mhwood> If we're going to make it configurable, push it into the authz 
model instead of proliferating dspace.cfg stuff.
[20:29] <tdonohue> mhwood -- although I agree conceptually (for long term), all 
the other "delegated admin auth" stuff is already in dspace.cfg. So, I was just 
maintaining consistency for now
[20:29] <mhwood> OK, I'm not familiar with that bit.
[20:30] <tdonohue> but, once the other 'delegated admin auth" stuff is moved 
out of dspace.cfg, then, yes, I agree
[20:30] <tdonohue> This is the stuff in dspace.cfg : 
https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L319
[20:30] <kompewter> [ DSpace/dspace/config/dspace.cfg at master · 
DSpace/DSpace · GitHub ] - 
https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L319
[20:30] <mdiggory> delegated administration represents "actions" that a user 
role can perform...
[20:31] <tdonohue> so, it seems like we just need a new configurable action for 
now -- an "export-metadata" action.
[20:31] <mdiggory> Let me ask a tough question here... delegated admin actually 
controls exposure of UI interfaces, but does it actually result in testing the 
users ability to alter the data model and run the "business logic" that the UI 
interacts with?
[20:32] <tdonohue> I think the answer is *yes* (it actually blocks users in the 
business logic as well). But, I could be wrong (been a while since I looked at 
the code)
[20:32] <mhwood> A good point. We shouldn't be controlling access through UI 
exposure, because we have scads of UIs and they tend to diverge.
[20:33] <mdiggory> 
https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/authorize/AuthorizeConfiguration.java
[20:33] <kompewter> [ 
DSpace/dspace-api/src/main/java/org/dspace/authorize/AuthorizeConfiguration.java
 at master · DSpace/DSpace · GitHub ] - 
https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/authorize/AuthorizeConfiguration.java
[20:34] <tdonohue> In any case, we've spent a large amount of time on this one 
topic :)
[20:34] <tdonohue> there's a lot of great info here though -- need to add to 
the notes of Ds-1046
[20:34] <tdonohue> Anyone interested in looking more closely at Ds-1046?
[20:35] <tdonohue> (i.e. anyone want to build out this use case)
[20:37] <tdonohue> ok. hearing none right now. Ds-1046 Summary: We brainstormed 
this out for a bit. (Notes need to be posted to ticket). Needs a developer 
volunteer to investigate / implement
...
[20:38] <mdiggory> just one last comment on above... AuthorizeConfiguration is 
used by AuthorizeUtil and the primary DSO objects
...
[20:41] <mdiggory> tdonohue: very last comment.... AuthorizeUtil is used 
throughout the UIs
                
> Add metadata export for community and collection managers
> ---------------------------------------------------------
>
>                 Key: DS-1046
>                 URL: https://jira.duraspace.org/browse/DS-1046
>             Project: DSpace
>          Issue Type: Improvement
>          Components: DSpace API, JSPUI, XMLUI
>            Reporter: Stuart Lewis
>
> The latter use is what I had in mind.
> But also just for administrative use within our own team. I am happy to let
> a whole range of staff export metadata, but don't necessarily want them to
> import that data.
> It would also support the requests, which I expect to see increase in the
> future, to provide a list of publications for a departing academic who then
> wants to load data into the repository of their new institution.
> Cheers,
> Vanessa Barrett
> Digital Services Librarian
> The University of Adelaide, AUSTRALIA 5005
> Ph    : +61 8 8303 4625
> e-mail: vanessa.barr...@adelaide.edu.au
> CRICOS Provider Number 00123M
> -----------------------------------------------------------
> IMPORTANT: This message may contain confidential or legally privileged
> information. If you think it was sent to you by mistake, please delete all
> copies and advise the sender. For the purposes of the SPAM Act 2003, this
> email is authorised by The University of Adelaide. 
> Think green: read on the screen
> -----Original Message-----
> From: Stuart Lewis [mailto:s.le...@auckland.ac.nz] 
> Sent: Tuesday, 4 October 2011 4:18 PM
> To: <vanessa.barr...@adelaide.edu.au>
> Cc: <dspace-gene...@lists.sourceforge.net>
> Subject: Re: [Dspace-general] Export metadata function for
> non-administrators
> Hi Vanessa,
> At present this is not supported - metadata export and import is restricted
> to system administrators.  Adding the ability for for 'community
> adminsitrators' to export the metadata should be relatively easy.
> For what reason do you want to export the data?  If it is for them to export
> metadata, edit it, then send it to you for re-upload?  Or is it for them to
> have a copy of the data for use in other systems, perhaps web pages?
> Thanks,
> Stuart Lewis
> Digital Development Manager
> Te Tumu Herenga The University of Auckland Library
> Auckland Mail Centre, Private Bag 92019, Auckland 1142, New Zealand
> Ph: +64 (0)9 373 7599 x81928
> On 4/10/2011, at 6:30 PM, Vanessa Barrett wrote:
> Hi All,
> Sending this again as I got no replies last time.  From that I am assuming
> I am asking too much!!!
> I am running DSpace 1.6 and making good use of the metadata export and
> Import metadata functions to perform batch updates to records.
> What I'd like to offer to some trusted users (i.e. University of Adelaide
> staff) is the ability to use the function of Export Metadata, but not to
> have access to the other administrator functions of Import metadata, editing
> records, creating communities etc.
> Can I exercise this level of control?
> It would be great to offer to researchers the ability to export metadata
> for their own publications or for school admin staff to do so for their
> authors.
> Cheers,
> Vanessa Barrett
> Digital Services Librarian
> The University of Adelaide, AUSTRALIA 5005
> Ph    : +61 8 8303 4625
> e-mail: vanessa.barr...@adelaide.edu.au
> CRICOS Provider Number 00123M
> -----------------------------------------------------------
> IMPORTANT: This message may contain confidential or legally privileged
> information. If you think it was sent to you by mistake, please delete all
> copies and advise the sender. For the purposes of the SPAM Act 2003, this
> email is authorised by The University of Adelaide.
> Think green: read on the screen
> ----------------------------------------------------------------------------
> --
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1_________________________________________
> ______
> Dspace-general mailing list
> dspace-gene...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-general

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to