AB
Al Bersch
Tue, Mar 3, 2015 5:48 PM
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
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
RL
Ray Lee
Wed, Mar 4, 2015 12:27 AM
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
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
>
>
AB
Al Bersch
Wed, Mar 4, 2015 1:00 AM
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
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
SS
Susan Stone
Wed, Mar 4, 2015 1:13 AM
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
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
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
>
>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
JB
John B. LOWE
Wed, Mar 4, 2015 2:53 AM
Al, et al.,
There are no webapps (that I know of!) that "do cataloging", though there
are several that update selected fields in cataloging records.
For example, PAHMA has a webapp that allows users to select a range of
object locations and a "fieldset" (a set of fields to review and update)
and update those fields for objects in those locations:
https://dev.cspace.berkeley.edu/webappmanual/pahma-webappmanual.html#kir
Of course, a webapp to "do cataloging" could be written, and indeed, it's
been suggested that this be put on the list of things to do...
John
On Tue, Mar 3, 2015 at 5:00 PM, Al Bersch abersch@museumca.org 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, et al.,
There are no webapps (that I know of!) that "do cataloging", though there
are several that update selected fields in cataloging records.
For example, PAHMA has a webapp that allows users to select a range of
object locations and a "fieldset" (a set of fields to review and update)
and update those fields for objects in those locations:
https://dev.cspace.berkeley.edu/webappmanual/pahma-webappmanual.html#kir
Of course, a webapp to "do cataloging" could be written, and indeed, it's
been suggested that this be put on the list of things to do...
John
On Tue, Mar 3, 2015 at 5:00 PM, Al Bersch <abersch@museumca.org> 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
>
>
MF
Megan Forbes
Wed, Mar 4, 2015 2:03 PM
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.
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.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-8468
Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
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.
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<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
_______________________________________________
Talk mailing list
Talk@lists.collectionspace.org<mailto:Talk@lists.collectionspace.org>
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
AR
Aron Roberts
Wed, Mar 4, 2015 4:07 PM
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.
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
On Wed, Mar 4, 2015 at 6:03 AM, Megan Forbes <megan.forbes@lyrasis.org>
wrote:
> It does seem that disabling computed current location should be easier
> than building a new web app for cataloging. Then location would not appear
> in terms used in the cataloging sidebar, and "none" permissions to
> location/movement/inventory would work properly.
>
Am speculating that doing this - disabling the computed current location
updating in Cataloging - primarily involves removing the event handler
code, that updates that field, from the Services layer source code tree,
and rebuilding that layer. That code is all contained within a single
directory:
https://github.com/collectionspace/services/tree/master/3rdparty/nuxeo/nuxeo-platform-listener/updateobjectlocationonmove
You may also need to comment out references to that directory in the Ant
buildfile for a parent directory:
https://github.com/collectionspace/services/blob/master/3rdparty/nuxeo/nuxeo-platform-listener/build.xml
Untried by moi, but worth experimenting with: if this is an option that
might work. Keep in mind that if there are existing values in that field,
they'll likely need to be removed, as well; a SQL UPDATE might do that.
Aron
>
> Those who do have permission to view current location will need to click
> on the l/m/i tab to see the information, but it will be much easier to hide
> from those who aren't allowed.
>
>
> Giving non-staff "none" permission to valuation should work as expected
> - valuation should not appear as a secondary tab, in the related records
> listing, in search, etc.
>
>
> Megan Forbes
> CollectionSpace Community Outreach and Support Manager
> *megan.forbes@lyrasis.org <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
>
>
RM
Richard Millet
Wed, Mar 4, 2015 4:21 PM
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.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:
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.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
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<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
MF
Megan Forbes
Wed, Mar 4, 2015 4:35 PM
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.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:
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.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
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<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
AR
Aron Roberts
Wed, Mar 4, 2015 4:56 PM
Riffing on my earlier comment, and Richard's:
What Richard is suggesting, when he mentioned the relevant "Nuxeo bundle",
is removing just this file
$CSPACE_JEESERVER_HOME/nuxeo-server/plugins/org.collectionspace.services.listener.updateobjectlocationonmove-4.1-SNAPSHOT.jar
and then restarting Tomcat.
That should do the trick of turning off updates to the computed current
location field in Cataloging - fast, simple, easy.
The concern I had is that, on a subsequent rebuild of the Services layer,
that file might be re-created and re-deployed, and that behavior might
unexpectedly return, somewhere down the road. To prevent that, a probably
better way (than the way I'd previously suggested) might be (again untried
by moi, but quick to verify):
In the Services layer source code tree:
- cd to services/3rdparty/nuxeo/nuxeo-platform-listener
- enter: "ant undeploy" (this will remove all of the 'Nuxeo bundle' JAR
files in $CSPACE_JEESERVER_HOME/nuxeo-server/plugins pertaining to event
listeners/handlers)
- In services/3rdparty/nuxeo/nuxeo-platform-listener/build.xml, comment out
all lines containing 'updateobjectlocationonmove'
- enter: "ant deploy" (this will re-create and re-deploy all of the
previously-removed event listener/handler JARs, except for the
'updateobjectlocationonmove' handler)
On Wed, Mar 4, 2015 at 8:21 AM, Richard Millet richard.millet@lyrasis.org
wrote:
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.
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
Riffing on my earlier comment, and Richard's:
What Richard is suggesting, when he mentioned the relevant "Nuxeo bundle",
is removing just this file
$CSPACE_JEESERVER_HOME/nuxeo-server/plugins/org.collectionspace.services.listener.updateobjectlocationonmove-4.1-SNAPSHOT.jar
and then restarting Tomcat.
That should do the trick of turning off updates to the computed current
location field in Cataloging - fast, simple, easy.
The concern I had is that, on a subsequent rebuild of the Services layer,
that file might be re-created and re-deployed, and that behavior might
unexpectedly return, somewhere down the road. To prevent that, a probably
better way (than the way I'd previously suggested) might be (again untried
by moi, but quick to verify):
In the Services layer source code tree:
* cd to services/3rdparty/nuxeo/nuxeo-platform-listener
* enter: "ant undeploy" (this will remove all of the 'Nuxeo bundle' JAR
files in $CSPACE_JEESERVER_HOME/nuxeo-server/plugins pertaining to event
listeners/handlers)
* In services/3rdparty/nuxeo/nuxeo-platform-listener/build.xml, comment out
all lines containing 'updateobjectlocationonmove'
* enter: "ant deploy" (this will re-create and re-deploy all of the
previously-removed event listener/handler JARs, *except* for the
'updateobjectlocationonmove' handler)
On Wed, Mar 4, 2015 at 8:21 AM, Richard Millet <richard.millet@lyrasis.org>
wrote:
> It should be possible to disable the computed current location updating
> without having to touch the source code and without having to rebuild
> anything. The event handler is a Nuxeo bundle that can be removed from the
> tomcat/nuxeo-server/plugins directory. Removing that bundle and restarting
> tomcat should do it.
>
>
>
> ------------------------------
> *From:* Talk <talk-bounces@lists.collectionspace.org> on behalf of Aron
> Roberts <aron@socrates.berkeley.edu>
> *Sent:* Wednesday, March 4, 2015 8:07 AM
> *To:* Megan Forbes
> *Cc:* Susan Stone; talk
> *Subject:* Re: [Talk] Permissions
>
> On Wed, Mar 4, 2015 at 6:03 AM, Megan Forbes <megan.forbes@lyrasis.org>
> wrote:
>
>> It does seem that disabling computed current location should be easier
>> than building a new web app for cataloging. Then location would not appear
>> in terms used in the cataloging sidebar, and "none" permissions to
>> location/movement/inventory would work properly.
>>
> Am speculating that doing this - disabling the computed current location
> updating in Cataloging - primarily involves removing the event handler
> code, that updates that field, from the Services layer source code tree,
> and rebuilding that layer. That code is all contained within a single
> directory:
>
>
> https://github.com/collectionspace/services/tree/master/3rdparty/nuxeo/nuxeo-platform-listener/updateobjectlocationonmove
>
> You may also need to comment out references to that directory in the
> Ant buildfile for a parent directory:
>
>
> https://github.com/collectionspace/services/blob/master/3rdparty/nuxeo/nuxeo-platform-listener/build.xml
>
> Untried by moi, but worth experimenting with: if this is an option
> that might work. Keep in mind that if there are existing values in that
> field, they'll likely need to be removed, as well; a SQL UPDATE might do
> that.
>
> Aron
>
>
>
>
>
>>
>> Those who do have permission to view current location will need to
>> click on the l/m/i tab to see the information, but it will be much easier
>> to hide from those who aren't allowed.
>>
>>
>> Giving non-staff "none" permission to valuation should work as expected
>> - valuation should not appear as a secondary tab, in the related records
>> listing, in search, etc.
>>
>>
>> Megan Forbes
>> CollectionSpace Community Outreach and Support Manager
>> *megan.forbes@lyrasis.org <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
>>
>>
>
