talk@lists.collectionspace.org
WE HAVE SUNSET THIS LISTSERV - Join us at collectionspace@lyrasislists.org
View all threadsPermissions
Yes, this would complicate reporting quite a bit. That field is very useful for most users.
Chris
On 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:
You may also need to comment out references to that directory in the Ant buildfile for a parent directory:
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
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?
Good point, Megan. As Chris also just now mentioned, it would indeed
remove that benefit.
As an alternative, prior to the creation of the 'computed current
location' field and code to update its values, John Lowe (and possibly
other UCB collaborators?) created a PostgreSQL function that essentially
returned the equivalent data - the current location for each object. That
function was fairly complicated, as seen in this example:
http://issues.collectionspace.org/browse/PAHMA-359
(This one is further complicated by PAHMA's use of moveable 'crates',
supplementing fixed storage locations.)
Aron
--
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 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:
You may also need to comment out references to that directory in the
Ant buildfile for a parent directory:
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 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 listTalk@lists.collectionspace.orghttp://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
Hi all,
Thanks so much once again for troubleshooting this with us!
I think we would certainly need to weigh the disadvantages of NOT being
able to smoothly report on locations, if we disabled the computed current
location field. Other than the fact that it is visible to all, we really
like the computed current location feature, and it woudl be a shame to give
it up.
I'm intrigued by Megan's suggestion of building a second tenant with
limited fields for researchers and volunteers. If volunteers or non-staff
were entering information, we'd need to be able to find a way to connect
that back up with the 'main' tenant.
As for the sidebar issue, Susan's suggestion that we put restricted
information in custom fields that won't show up in the sidebar should work
for us - though if we do create a system where only staff have access to a
main tenant, visibility in the sidebar might cease to be an issue.
Thanks again for all this help - we'll continue to mull on this.
Al
On Wed, Mar 4, 2015 at 9:24 AM, Aron Roberts aron@socrates.berkeley.edu
wrote:
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?
Good point, Megan. As Chris also just now mentioned, it would indeed
remove that benefit.
As an alternative, prior to the creation of the 'computed current
location' field and code to update its values, John Lowe (and possibly
other UCB collaborators?) created a PostgreSQL function that essentially
returned the equivalent data - the current location for each object. That
function was fairly complicated, as seen in this example:
http://issues.collectionspace.org/browse/PAHMA-359
(This one is further complicated by PAHMA's use of moveable 'crates',
supplementing fixed storage locations.)
Aron
--
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 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:
You may also need to comment out references to that directory in the
Ant buildfile for a parent directory:
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 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 listTalk@lists.collectionspace.orghttp://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
--
Al Bersch
Collections Systems Manager
Oakland Museum of California
1000 Oak Street, Oakland, CA 94607
abersch@museumca.org
510-318-8468
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 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:
You may also need to comment out references to that directory in the
Ant buildfile for a parent directory:
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 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 listTalk@lists.collectionspace.orghttp://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
If we separate the base DB URL config property into one for the Nuxeo DB and a different one for the CSpace(authn/authz) DB then we should be able to prevent the login problem. In other words, multiple tenants could have their own authn/authz database and still share a common Nuxeo DB/repo.
t
From: Ray Lee rhlee@berkeley.edu
Sent: Wednesday, March 4, 2015 12:36 PM
To: Megan Forbes
Cc: Richard Millet; Aron Roberts; talk
Subject: Re: [Talk] Permissions
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.orgmailto: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.orgmailto:megan.forbes@lyrasis.org
800.999.8558 x 2917tel:800.999.8558%20x%202917 Main
917.267.9676tel:917.267.9676 Cell
meganbforbes Skype
From: Talk <talk-bounces@lists.collectionspace.orgmailto:talk-bounces@lists.collectionspace.org> on behalf of Richard Millet <richard.millet@lyrasis.orgmailto: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.orgmailto:talk-bounces@lists.collectionspace.org> on behalf of Aron Roberts <aron@socrates.berkeley.edumailto: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.orgmailto: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:
You may also need to comment out references to that directory in the Ant buildfile for a parent directory:
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.orgmailto:megan.forbes@lyrasis.org
800.999.8558 x 2917tel:800.999.8558%20x%202917 Main
917.267.9676tel:917.267.9676 Cell
meganbforbes Skype
From: Talk <talk-bounces@lists.collectionspace.orgmailto:talk-bounces@lists.collectionspace.org> on behalf of Susan Stone <sstone@berkeley.edumailto:sstone@berkeley.edu>
Sent: Tuesday, March 3, 2015 8:13 PM
To: talk@lists.collectionspace.orgmailto: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.edumailto: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.orgmailto: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.orgmailto:abersch@museumca.org
510-318-8468tel:510-318-8468
Talk mailing list
Talk@lists.collectionspace.orgmailto: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.orgmailto:abersch@museumca.org
510-318-8468tel:510-318-8468
Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Ray, et al.,
Yes, an interesting idea to make separate UIs available. Ray and I just
talked, and it bears noting that there is a problem with two CSpace servers
updating the same database at the same time -- but this problem exists
already even in the single server case, and the webapps too suffer from it,
and while it has bitten us in the past here at UCB, we are fortunately the
bites were nibbles.
Furthermore (without getting in to details), it might be a challenge to
keep people using a limited UI tenant" from being able (via REST service
calls) to view the data you are trying to hide from them.
John
On Wed, Mar 4, 2015 at 12:36 PM, Ray Lee rhlee@berkeley.edu 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 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:
You may also need to comment out references to that directory in the
Ant buildfile for a parent directory:
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 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 listTalk@lists.collectionspace.orghttp://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
I might be misunderstanding Susan's suggestion, but it seems like you could
get the same effect by reconfiguring the movement record so that the fields
shown in the sidebar are non-sensitive fields. Or if there aren't any
non-sensitive fields, you could add a couple extension fields, but you
wouldn't have to store anything in them. They could be blank dummy fields.
Ray
On Wed, Mar 4, 2015 at 9:48 AM, Al Bersch abersch@museumca.org wrote:
Hi all,
Thanks so much once again for troubleshooting this with us!
I think we would certainly need to weigh the disadvantages of NOT being
able to smoothly report on locations, if we disabled the computed current
location field. Other than the fact that it is visible to all, we really
like the computed current location feature, and it woudl be a shame to give
it up.
I'm intrigued by Megan's suggestion of building a second tenant with
limited fields for researchers and volunteers. If volunteers or non-staff
were entering information, we'd need to be able to find a way to connect
that back up with the 'main' tenant.
As for the sidebar issue, Susan's suggestion that we put restricted
information in custom fields that won't show up in the sidebar should work
for us - though if we do create a system where only staff have access to a
main tenant, visibility in the sidebar might cease to be an issue.
Thanks again for all this help - we'll continue to mull on this.
Al
On Wed, Mar 4, 2015 at 9:24 AM, Aron Roberts aron@socrates.berkeley.edu
wrote:
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?
Good point, Megan. As Chris also just now mentioned, it would indeed
remove that benefit.
As an alternative, prior to the creation of the 'computed current
location' field and code to update its values, John Lowe (and possibly
other UCB collaborators?) created a PostgreSQL function that essentially
returned the equivalent data - the current location for each object. That
function was fairly complicated, as seen in this example:
http://issues.collectionspace.org/browse/PAHMA-359
(This one is further complicated by PAHMA's use of moveable 'crates',
supplementing fixed storage locations.)
Aron
--
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 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:
You may also need to comment out references to that directory in the
Ant buildfile for a parent directory:
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 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 listTalk@lists.collectionspace.orghttp://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
--
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
John,
In my last post, I mentioned that it's very possible we can create separate SEPARATE authn/authz databases for each tenant. This would prevent the "limited" tenant from getting access to data in the shared Nuxeo repo -even via the REST API.
-Richard
From: Talk talk-bounces@lists.collectionspace.org on behalf of John B. LOWE jblowe@berkeley.edu
Sent: Wednesday, March 4, 2015 1:26 PM
To: Ray Lee
Cc: talk
Subject: Re: [Talk] Permissions
Ray, et al.,
Yes, an interesting idea to make separate UIs available. Ray and I just talked, and it bears noting that there is a problem with two CSpace servers updating the same database at the same time -- but this problem exists already even in the single server case, and the webapps too suffer from it, and while it has bitten us in the past here at UCB, we are fortunately the bites were nibbles.
Furthermore (without getting in to details), it might be a challenge to keep people using a limited UI tenant" from being able (via REST service calls) to view the data you are trying to hide from them.
John
On Wed, Mar 4, 2015 at 12:36 PM, Ray Lee <rhlee@berkeley.edumailto:rhlee@berkeley.edu> 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.orgmailto: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.orgmailto:megan.forbes@lyrasis.org
800.999.8558 x 2917tel:800.999.8558%20x%202917 Main
917.267.9676tel:917.267.9676 Cell
meganbforbes Skype
From: Talk <talk-bounces@lists.collectionspace.orgmailto:talk-bounces@lists.collectionspace.org> on behalf of Richard Millet <richard.millet@lyrasis.orgmailto: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.orgmailto:talk-bounces@lists.collectionspace.org> on behalf of Aron Roberts <aron@socrates.berkeley.edumailto: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.orgmailto: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:
You may also need to comment out references to that directory in the Ant buildfile for a parent directory:
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.orgmailto:megan.forbes@lyrasis.org
800.999.8558 x 2917tel:800.999.8558%20x%202917 Main
917.267.9676tel:917.267.9676 Cell
meganbforbes Skype
From: Talk <talk-bounces@lists.collectionspace.orgmailto:talk-bounces@lists.collectionspace.org> on behalf of Susan Stone <sstone@berkeley.edumailto:sstone@berkeley.edu>
Sent: Tuesday, March 3, 2015 8:13 PM
To: talk@lists.collectionspace.orgmailto: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.edumailto: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.orgmailto: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.orgmailto:abersch@museumca.org
510-318-8468tel:510-318-8468
Talk mailing list
Talk@lists.collectionspace.orgmailto: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.orgmailto:abersch@museumca.org
510-318-8468tel:510-318-8468
Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Ray,
I wasn't sure how relations knew which fields to display, but yes, the
data could go in any field not configured to show up. I was just trying
to get better minds to come up with some ideas.
But having no information in the sidebar records (except a date if that
was acceptable) might not be very useful, and I'm not sure if the same
fields are the ones displayed (or not) in search results.
Susan
On 03/04/2015 01:42 PM, Ray Lee wrote:
I might be misunderstanding Susan's suggestion, but it seems like you
could get the same effect by reconfiguring the movement record so that
the fields shown in the sidebar are non-sensitive fields. Or if there
aren't any non-sensitive fields, you could add a couple extension
fields, but you wouldn't have to store anything in them. They could be
blank dummy fields.
Ray
On Wed, Mar 4, 2015 at 9:48 AM, Al Bersch <abersch@museumca.org
mailto:abersch@museumca.org> wrote:
Hi all,
Thanks so much once again for troubleshooting this with us!
I think we would certainly need to weigh the disadvantages of NOT
being able to smoothly report on locations, if we disabled the
computed current location field. Other than the fact that it is
visible to all, we really like the computed current location
feature, and it woudl be a shame to give it up.
I'm intrigued by Megan's suggestion of building a second tenant
with limited fields for researchers and volunteers. If volunteers
or non-staff were entering information, we'd need to be able to
find a way to connect that back up with the 'main' tenant.
As for the sidebar issue, Susan's suggestion that we put
restricted information in custom fields that won't show up in the
sidebar should work for us - though if we do create a system where
only staff have access to a main tenant, visibility in the sidebar
might cease to be an issue.
Thanks again for all this help - we'll continue to mull on this.
Al
On Wed, Mar 4, 2015 at 9:24 AM, Aron Roberts
<aron@socrates.berkeley.edu <mailto:aron@socrates.berkeley.edu>>
wrote:
On Wed, Mar 4, 2015 at 8:35 AM, Megan Forbes
<megan.forbes@lyrasis.org <mailto: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?
Good point, Megan. As Chris also just now mentioned, it
would indeed remove that benefit.
As an alternative, prior to the creation of the 'computed
current location' field and code to update its values, John
Lowe (and possibly other UCB collaborators?) created a
PostgreSQL function that essentially returned the equivalent
data - the current location for each object. That function was
fairly complicated, as seen in this example:
http://issues.collectionspace.org/browse/PAHMA-359
(This one is further complicated by PAHMA's use of moveable
'crates', supplementing fixed storage locations.)
Aron
--
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 <mailto:megan.forbes@lyrasis.org>_
800.999.8558 x 2917 <tel:800.999.8558%20x%202917> Main
917.267.9676 <tel:917.267.9676> Cell
meganbforbes Skype
------------------------------------------------------------------------
*From:* Talk <talk-bounces@lists.collectionspace.org
<mailto:talk-bounces@lists.collectionspace.org>> on behalf
of Richard Millet <richard.millet@lyrasis.org
<mailto: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
<mailto:talk-bounces@lists.collectionspace.org>> on behalf
of Aron Roberts <aron@socrates.berkeley.edu
<mailto: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
<mailto: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
<mailto:megan.forbes@lyrasis.org>_
800.999.8558 x 2917 <tel:800.999.8558%20x%202917> Main
917.267.9676 <tel:917.267.9676> Cell
meganbforbes Skype
------------------------------------------------------------------------
*From:* Talk <talk-bounces@lists.collectionspace.org
<mailto:talk-bounces@lists.collectionspace.org>> on
behalf of Susan Stone <sstone@berkeley.edu
<mailto:sstone@berkeley.edu>>
*Sent:* Tuesday, March 3, 2015 8:13 PM
*To:* talk@lists.collectionspace.org
<mailto: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 <mailto: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
<mailto: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
<mailto:abersch@museumca.org>
510-318-8468 <tel:510-318-8468>
_______________________________________________
Talk mailing list
Talk@lists.collectionspace.org
<mailto: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 <mailto:abersch@museumca.org>
510-318-8468 <tel:510-318-8468>
_______________________________________________
Talk mailing list
Talk@lists.collectionspace.org <mailto:Talk@lists.collectionspace.org>
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
_______________________________________________
Talk mailing list
Talk@lists.collectionspace.org
<mailto:Talk@lists.collectionspace.org>
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
_______________________________________________
Talk mailing list
Talk@lists.collectionspace.org
<mailto: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 <mailto:abersch@museumca.org>
510-318-8468 <tel:510-318-8468>
_______________________________________________
Talk mailing list
Talk@lists.collectionspace.org <mailto: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
Seems like a widely useful capability to add to cspace. I hope you do it!
Susan
On 03/04/2015 01:44 PM, Richard Millet wrote:
John,
In my last post, I mentioned that it's very possible we can create
separate SEPARATE authn/authz databases for each tenant. This would
prevent the "limited" tenant from getting access to data in the shared
Nuxeo repo -even via the REST API.
-Richard
From: Talk talk-bounces@lists.collectionspace.org on behalf of
John B. LOWE jblowe@berkeley.edu
Sent: Wednesday, March 4, 2015 1:26 PM
To: Ray Lee
Cc: talk
Subject: Re: [Talk] Permissions
Ray, et al.,
Yes, an interesting idea to make separate UIs available. Ray and I
just talked, and it bears noting that there is a problem with two
CSpace servers updating the same database at the same time -- but this
problem exists already even in the single server case, and the webapps
too suffer from it, and while it has bitten us in the past here at
UCB, we are fortunately the bites were nibbles.
Furthermore (without getting in to details), it might be a challenge
to keep people using a limited UI tenant" from being able (via REST
service calls) to view the data you are trying to hide from them.
John
On Wed, Mar 4, 2015 at 12:36 PM, Ray Lee <rhlee@berkeley.edu
mailto:rhlee@berkeley.edu> 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 <mailto: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 <mailto:megan.forbes@lyrasis.org>_
800.999.8558 x 2917 <tel:800.999.8558%20x%202917> Main
917.267.9676 <tel:917.267.9676> Cell
meganbforbes Skype
------------------------------------------------------------------------
*From:* Talk <talk-bounces@lists.collectionspace.org
<mailto:talk-bounces@lists.collectionspace.org>> on behalf of
Richard Millet <richard.millet@lyrasis.org
<mailto: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
<mailto:talk-bounces@lists.collectionspace.org>> on behalf of
Aron Roberts <aron@socrates.berkeley.edu
<mailto: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 <mailto: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 <mailto:megan.forbes@lyrasis.org>_
800.999.8558 x 2917 <tel:800.999.8558%20x%202917> Main
917.267.9676 <tel:917.267.9676> Cell
meganbforbes Skype
------------------------------------------------------------------------
*From:* Talk <talk-bounces@lists.collectionspace.org
<mailto:talk-bounces@lists.collectionspace.org>> on behalf
of Susan Stone <sstone@berkeley.edu
<mailto:sstone@berkeley.edu>>
*Sent:* Tuesday, March 3, 2015 8:13 PM
*To:* talk@lists.collectionspace.org
<mailto: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 <mailto: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 <mailto: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 <mailto:abersch@museumca.org>
510-318-8468 <tel:510-318-8468>
_______________________________________________
Talk mailing list
Talk@lists.collectionspace.org
<mailto: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 <mailto:abersch@museumca.org>
510-318-8468 <tel:510-318-8468>
_______________________________________________
Talk mailing list
Talk@lists.collectionspace.org <mailto:Talk@lists.collectionspace.org>
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
_______________________________________________
Talk mailing list
Talk@lists.collectionspace.org
<mailto:Talk@lists.collectionspace.org>
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
_______________________________________________
Talk mailing list
Talk@lists.collectionspace.org
<mailto:Talk@lists.collectionspace.org>
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
_______________________________________________
Talk mailing list
Talk@lists.collectionspace.org <mailto: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