Hi Stefan, I'd recommend starting by creating a ticket in our ticketing system [1] (to describe the use case, perhaps even with screenshots or examples of the workflow). After creating a ticket, you are welcome to submit one or both of your proposed PRs, and developers can work with you to decide which one may be more reasonable (as needed).
The general DSpace code contribution process is documented at: https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines If you have further questions, you are welcome to ask them on a mailing list, or you could consider joining our Slack ( https://wiki.duraspace.org/display/DSPACE/Slack), as a lot of the core developers tend to communicate on Slack on a day to day basis (take a look at the #dev channel in Slack, especially). Let us know if you have further questions, and thanks for considering giving back to the project! We rely entirely on code contributions to DSpace, as there is no centralized developer team. So, all code contributions, feedback, documentation, support and releases is all managed by volunteers working at various institutions in our community. - Tim [1] JIRA: https://jira.duraspace.org/projects/DS/summary On Wed, Mar 21, 2018 at 5:53 AM Stefan Kombrink <[email protected]> wrote: > Hello everyone, > > at our institution we plan to utilize DSpace as backend for an archival > service to allow users to instantly submit respective publication > records of their archived research data. > For that purpose we would like to create a publication item with > metadata via Swordv2. We do so by the use of a dedicated user that has > submission privileges, and Swordv2 + the feature onBehalfOf enabled. > > We figured it is not possible to enable item creation via onBehalfOf > exclusively for a list of dedicated users, but we find it necessary to > provide good security to participating institutes. > > This is why I implemented two ways to define a list of accounts with > exclusive access to create items via Swordv2. > > You can check the two proposals Ive implemented to enable such a > functionality: > > The first one disables Obo submission for anyone except mediators (those > who can issue updates on submitted items). Probably bad, since it > changes default behavior. > > https://github.com/DSpace/DSpace/compare/dspace-6_x...54r4:dspace-6.2_OboFixVariant1 > > The second one does NOT change default behavior and thus introduces an > additional configuration option > > https://github.com/DSpace/DSpace/compare/dspace-6_x...54r4:dspace-6.2_OboFixVariant2 > > Is it okay to issue two pull requests, or am I recommended to proceed > differently? > > We are interested in feedback for this feature and get the functionality > in some way or another into the mainline repo. Is this the right place > to discuss this? > > Looking forward for your feedback & best regards > Stefan > > -- > Stefan Kombrink > Universität Ulm > Kommunikations- und Informationszentrum (kiz) > Abteilung Informationsmedien > +49-731-50-31482 <+49%20731%205031482> > > -- > You received this message because you are subscribed to the Google Groups > "DSpace Technical Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > -- Tim Donohue Technical Lead for DSpace & DSpaceDirect DuraSpace.org | DSpace.org | DSpaceDirect.org -- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
