It seems that the existing CSPACE-5985 is the right place to track this issue. Let's continue this exchange of ideas in JIRA at CSPACE-5985. For those of you without edit permissions in the CollectionSpace JIRA, please feel free to add comments to this email thread. On Oct 2, 2014, at 9:35 PM, Richard Millet <richard.millet@berkeley.edu> wrote: > I'll create a JIRA to track this. We'll need to come up with a proper permission mapping for batch jobs. Batch jobs that add or modify data should require full CRUDL permissions. Ones that don't should require just the RL permissions. The batch invocation context should declare the permission necessary to invoke (run) the batch job so the service layer can enforce it. > > On Oct 2, 2014, at 7:03 PM, Aron Roberts <aronroberts@gmail.com> wrote: > >> Good point. I'm not sure either how the current permissions groups pertain to invocation privileges for batch jobs and reports. >> >> One minor data point: on creating a new role, even when setting all the UI-visible perms in the Administration tab to "None" (a list of perms which did not include any permissions pertinent to Reporting or Batch, for either CRUDL or invocation), that new role continued to retain CRUDL perms for the 'batch' resource: >> >> cspace=# select * from permissions_roles where permission_resource like '%batch%'; >> ... >> 2244 | CRUDL | 2014-10-02 18:54:38.3 | 1-batch-CRUDL | batch | 64217da9-4b91-4f61-87a7-4470d0f6537e | ROLE_MY NEW ROLE >> >> >> >> On Thu, Oct 2, 2014 at 6:49 PM, Ray Lee <rhlee@berkeley.edu> wrote: >> Actually, I'm not sure there is an appropriate permission. Even if we could set read/write/delete on reporting and batch, there's no execute permission, right? >> >> Ray >> >> On Thu, Oct 2, 2014 at 6:43 PM, Ray Lee <rhlee@berkeley.edu> wrote: >> I think so, at least regardless of permissions that can be viewed and set in the UI. It's possible the services are checking for permissions on the reporting and batch services that aren't exposed through the UI, and that are defaulting to something permissive when roles are created. I'm not sure how that all works. >> >> Ray >> >> On Thu, Oct 2, 2014 at 6:23 PM, Aron Roberts <aronroberts@gmail.com> wrote: >> Does CSPACE-5985 also imply that any user, regardless of perms, can initiate batch jobs via the REST APIs? >> >> On Thu, Oct 2, 2014 at 6:21 PM, Aron Roberts <aronroberts@gmail.com> wrote: >> Nice catch, Ray. And this seems like a slam dunk-like easy decision, at least to me: let's defer adding the 'Run batch process' menu to (at least) v4.2, until we can provide more control over which users can run batch jobs, yes? >> >> Others' thoughts welcomed ... >> >> On Thu, Oct 2, 2014 at 6:15 PM, Ray Lee <rhlee@berkeley.edu> wrote: >> Megan, Richard, and community: >> I just remembered a gap in the batch process running capability that I was planning to contribute for 4.1. See CSPACE-5985, and the linked UCBG-253. Currently, batch jobs, as I believe is the case with reports, can be run by any user, regardless of permissions. This seems like it's especially a problem with batch jobs, since they modify data, and potentially a lot of it. Should CSPACE-5985 be fixed before this contribution goes in? It would certainly mean pushing it out to 4.2. >> >> Thanks, >> Ray >> >> >> On Thu, Oct 2, 2014 at 6:03 AM, Megan Forbes <megan.forbes@lyrasis.org> wrote: >> Thanks to everyone who responded to the code contribution proposals. Having heard no arguments against, we propose to add the following to v4.1, due out in November: >> >> - Valuation control procedure (Walker, community vetted earlier this year) >> - Condition check procedure (Walker, community vetted earlier this year) >> - Alternating light and dark when repeating groups of fields (UCB) >> - Docking title bar (UCB) >> - Create new from existing uses template (UCB) >> - Run Batch added to UI (UCB) >> - Run Report opens report in a new tab/window (UCB) >> - Created & last modified dates displayed on records (UCB) >> >> If your organization has code it would like to contribute, please add it to the code contribution register on the project wiki (http://wiki.collectionspace.org/display/collectionspace/Code+Contribution+Register​) and send a note to the talk list. We're accepting contribution proposals for v4.2 now and will send out a note to the list summarizing them once v4.1 is out the door. >> >> Thanks, >> Megan >> >> >> >> Megan Forbes >> CollectionSpace Community Outreach and Support Manager >> megan.forbes@lyrasis.org >> 800.999.8558 x 2917 Main >> 917.267.9676 Cell >> meganbforbes Skype >> >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> >> >> >> >> >