Uploaded image for project: 'DSpace'
  1. DSpace
  2. DS-1046

Add metadata export for community and collection managers

    Details

    • Type: Improvement
    • Status: Volunteer Needed (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: DSpace API, JSPUI, XMLUI
    • Labels:
      None
    • Attachments:
      0
    • Comments:
      1
    • Documentation Status:
      Needed

      Description

      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.barrett@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 s.lewis@auckland.ac.nz
      Sent: Tuesday, 4 October 2011 4:18 PM
      To: <vanessa.barrett@adelaide.edu.au>
      Cc: <dspace-general@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.barrett@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-general@lists.sourceforge.net
      https://lists.sourceforge.net/lists/listinfo/dspace-general

        Attachments

          Activity

          Hide
          tdonohue Tim Donohue added a comment -

          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 (~mdiggory@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

          Show
          tdonohue Tim Donohue added a comment - 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 (~mdiggory@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

            People

            • Assignee:
              Unassigned
              Reporter:
              stuartlewis Stuart Lewis
            • Votes:
              2 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: