You may have to configure Nuxeo to be clustered, which they support already (have we ever tried this?). I think that would take care of the concurrency issues for the data. Patrick On Mar 4, 2015, at 12:36 PM, Ray Lee wrote: > Megan, > This is brilliant. I'm not sure if all the details can be worked out, but it has potential. The first problem is that in order to "see" the same data, two tenants would have to have the same tenant name (e.g. "lifesci") and tenant id (e.g. "2"). This wouldn't be allowed on a single CollectionSpace server. But, you could set up two CollectionSpace servers, each with a (lifesci, 2) tenant. Both of those servers could be configured to connect to the same database server. Since they have the same name, they would connect to the same database on that server, and since they have the same id, they would be able to access the same data in that database. > > At that point you could configure the tenant on one of the servers differently. You could remove the configuration for movement, valuation, and location records from one, so it wouldn't know about those record types at all. You could remove the computed current location field from collectionobjects. For true security, these changes would have to be done in the app layer, not just the UI. If the computed current location field is removed from the app layer, the event handler that sets it would probably also have to be disabled, as Aron has described. > > One problem I'm not sure how to solve: At that point, the two CSpace servers will share an authorization database. How would you only allow a user to log in to one, but not the other? > > It would be very interesting if someone tried this out. > > Ray > > > > On Wed, Mar 4, 2015 at 8:35 AM, Megan Forbes <megan.forbes@lyrasis.org> wrote: > > I know that computed current location has been useful in simplifying reporting - now that I've suggested disabling it, would doing that either the way Richard or Aron describes also remove this benefit? > > And a possibly crazy question - rather than create a cataloging webapp for volunteers/outside researchers, would it make any sense to create another tenant pointing to the same DB but with a very limited UI?​ > > > Megan Forbes > CollectionSpace Community Outreach and Support Manager > megan.forbes@lyrasis.org > 800.999.8558 x 2917 Main > 917.267.9676 Cell > meganbforbes Skype > > > From: Talk <talk-bounces@lists.collectionspace.org> on behalf of Richard Millet <richard.millet@lyrasis.org> > Sent: Wednesday, March 4, 2015 11:21 AM > To: Aron Roberts > Cc: talk > Subject: Re: [Talk] Permissions > > ​It should be possible to disable the computed current location updating without having to touch the source code and without having to rebuild anything. The event handler is a Nuxeo bundle that can be removed from the tomcat/nuxeo-server/plugins directory. Removing that bundle and restarting tomcat should do it. > > > From: Talk <talk-bounces@lists.collectionspace.org> on behalf of Aron Roberts <aron@socrates.berkeley.edu> > Sent: Wednesday, March 4, 2015 8:07 AM > To: Megan Forbes > Cc: Susan Stone; talk > Subject: Re: [Talk] Permissions > > On Wed, Mar 4, 2015 at 6:03 AM, Megan Forbes <megan.forbes@lyrasis.org> wrote: > ​It does seem that disabling computed current location should be easier than building a new web app for cataloging. Then location would not appear in terms used in the cataloging sidebar, and "none" permissions to location/movement/inventory would work properly. > Am speculating that doing this - disabling the computed current location updating in Cataloging - primarily involves removing the event handler code, that updates that field, from the Services layer source code tree, and rebuilding that layer. That code is all contained within a single directory: > > https://github.com/collectionspace/services/tree/master/3rdparty/nuxeo/nuxeo-platform-listener/updateobjectlocationonmove > > You may also need to comment out references to that directory in the Ant buildfile for a parent directory: > > https://github.com/collectionspace/services/blob/master/3rdparty/nuxeo/nuxeo-platform-listener/build.xml > > Untried by moi, but worth experimenting with: if this is an option that might work. Keep in mind that if there are existing values in that field, they'll likely need to be removed, as well; a SQL UPDATE might do that. > > Aron > > > > > > Those who do have permission to view current location will need to click on the l/m/i tab to see the information, but it will be much easier to hide from those who aren't allowed. > > Giving non-staff "none" permission to valuation should work as expected - valuation should not appear as a secondary tab, in the related records listing, in search, etc. > > Megan Forbes > CollectionSpace Community Outreach and Support Manager > megan.forbes@lyrasis.org > 800.999.8558 x 2917 Main > 917.267.9676 Cell > meganbforbes Skype > > > From: Talk <talk-bounces@lists.collectionspace.org> on behalf of Susan Stone <sstone@berkeley.edu> > Sent: Tuesday, March 3, 2015 8:13 PM > To: talk@lists.collectionspace.org > Subject: Re: [Talk] Permissions > > If the relations in the sidebar are the problem, could you make sure the actual location and valuation are in custom fields that won't show up in the relation in the sidebar? That might break the computed current location, but you might need to hide that anyway and implement it in an external webapp accessible to staff. > > Ray? > > Susan > > On 03/03/2015 05:00 PM, Al Bersch wrote: >> Hi Ray, >> >> Thanks for your response. Are you aware of situations where people are cataloging through webapps, or are the external webapps only for searching/viewing? >> >> For non-staff, it sounds like we'll have to resort to some kind of external tool like that. We were aware going into the migration that permissions would be less than ideal, so we are somewhat prepared for this situation. I'm hoping we can figure out some kind of situation where non-staff can catalog without seeing locations and valuations. >> >> thanks again - >> >> Al >> >> On Tue, Mar 3, 2015 at 4:27 PM, Ray Lee <rhlee@berkeley.edu> wrote: >> Hi Al, >> This kind of thing comes up pretty frequently at UC Berkeley museums, but we've had to make do with cspace's existing permission model. Sometimes this means allowing users to edit entire records, even if they really only need to be able to edit one field. Sometimes it means not allowing users to use cspace at all, but instead to use external webapps that pull a limited set of fields from cspace. There's no really good answer. >> >> It seems like there are two different ways of solving this. One would be to implement field-level permissions in the services layer. Then you could prevent a user from seeing the content of particular fields, e.g. computed current location. I think that would be a really big change. Another way, which is possibly less work, would be to continue using cspace's record type permssions, but to enforce them across relations and references. In other words, when listing related records, filter out ones that the user doesn't have read access to -- that would solve stuff showing up in the sidebar. And when retrieving records, filter out fields that contain refnames of records the user doesn't have read access to. I'm not sure if the services layer has any hooks to make it convenient to write this kind of code. I'm also not sure if the services layer, given a refname, even knows for sure what kind of record it references. In any case, code needs to be written. >> >> There are a few problems with using templates for this. Templates are only used to create records; on subsequent viewings, they revert to the default template. There is no way to limit a user only to be able to use certain templates. And most importantly, templates determine how a record is laid out, but they aren't a security mechanism. The entire record is still downloaded, and can be viewed in the browser's developer console. >> >> Ray >> >> On Tue, Mar 3, 2015 at 9:48 AM, Al Bersch <abersch@museumca.org> wrote: >> Hello all, >> >> I was wondering if anyone has experience/thoughts about the limiting visibility of the computed current location field in Cataloging. OMCA restricts access to information about object locations, as well as valuations, from non-staff. So there was some concern that volunteers and outside researchers would be able to see the Computed Current Location field in Cataloging. >> >> Jesse did a test and created a user role and user without access to Storage Authority or Location/movement/inventory. The new user couldn't load or create a new Storage Location or Movement record, but the user could still see on the right sidebar that a storage location and movement record existed (they weren't loadable, but they were visible). The user could also see the computed current location in Cataloging. >> >> I understand that this is a known issue, but I'm curious if anything is in the works to make a way to hide computed current location for some users, or if anyone has worked out any fixes - or even how people handle researcher requests to use the system. Do people make use of templates for outside researchers, or limit cspace use to staff? And are registrars comfortable with this? >> >> Thanks! >> >> Al >> >> >> >> >> >> -- >> Al Bersch >> Collections Systems Manager >> Oakland Museum of California >> 1000 Oak Street, Oakland, CA 94607 >> abersch@museumca.org >> 510-318-8468 >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> >> >> >> >> -- >> Al Bersch >> Collections Systems Manager >> Oakland Museum of California >> 1000 Oak Street, Oakland, CA 94607 >> abersch@museumca.org >> 510-318-8468 >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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