[
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 ([email protected]) 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: [email protected]
> 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:[email protected]]
> Sent: Tuesday, 4 October 2011 4:18 PM
> To: <[email protected]>
> Cc: <[email protected]>
> 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: [email protected]
> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
