talk@lists.collectionspace.org
WE HAVE SUNSET THIS LISTSERV - Join us at collectionspace@lyrasislists.org
View all threadsemployee data in CollectionSpace
Thanks for all your comments. I'm awaiting local feedback on our exact requirements before taking this discussion further. I get the impression that we can achieve most of what we need via schema extensions.
In the meantime I've used the Person service api to prototype a basic webpage for creating, viewing and deleting person details, and it was a relatively painless experience :-) I look forward to adding the Contact relations and trying out some schema extensions in 0.8.
/Chris
-----Oprindelig meddelelse-----
Fra: Patrick Schmitz [mailto:pschmitz@berkeley.edu]
Sendt: 24. juni 2010 23:26
Til: 'Aron Roberts'; Christopher Pott
Cc: talk@lists.collectionspace.org
Emne: RE: [Talk] employee data in CollectionSpace
Field-level security is planned for a later release, however, we'd have to
create a new class of permissions for "sharing" in this manner. This is
doable, but I'd want to know more about what you are trying to do, in the
hopes that work we did would be more generally reusable.
Another approach is to configure this access through the application layer,
but this would leave a security hole in the services, as Aron mentions
below.
Another possibility would be to group the sensitive data into a single
schema within Contact, and control access to that. In any case, we should
probably talk some more about your requirements.
Thanks, hope this helps -
Patrick
-----Original Message-----
From: talk-bounces@lists.collectionspace.org
[mailto:talk-bounces@lists.collectionspace.org] On Behalf Of
Aron Roberts
Sent: Thursday, June 24, 2010 6:49 AM
To: Christopher Pott
Cc: talk@lists.collectionspace.org
Subject: Re: [Talk] employee data in CollectionSpace
Hi Chris,
On Thu, Jun 24, 2010 at 12:33 AM, Christopher Pott
Christopher.Pott@smk.dk wrote:
Thanks for answering all my questions. There's just one
point I'm still unclear about.....
- the ability to mark individual fields for internet or intranet
publishing
You can let us know if this response might meet your needs
for this:
through the Person service, you can programmatically
retrieve Person
records and their associated Contact record(s), and extract
data from
selected Contact record fields for re-publishing. As one of many
options, a web application that generates dynamic pages -
using PHP,
ColdFusion, JSP, ASP, etc. - could presumably make these calls
directly to the CollectionSpace services layer.
That describes broadly what we'd like to accomplish, but
what I was trying to describe was a detail related to this
scenario - that we may need to allow an employee to mark any
of their own Contact fields as a field which they would allow
to be published internally, externally, niether or both. We
could create yet more fields (via schema extension) to hold
this information but I just wanted to check if there wasn't
already a method in place related to capturing metadata about
a field - in this case the fields visibility within different
web domains.
Others may wish to comment or correct; here are some
initial thoughts regarding your requirement:
The Contact schema - and to my knowledge, schemas for
objects and procedural entities more generally - currently
does not / do not expose any metadata on a per-field basis,
such as the 'permission to publish this field
[internally|externally]' flag you describe.
(Having that is a really interesting idea, by the way.)
If you add fields that you don't wish to have automatically
published, to an extension schema for Contacts, those fields
won't automatically appear in the web UI in a CollectionSpace
system. (To enable those to show up in the UI, you'd also
need to make changes in the App and UI layers; if you don't,
those fields will appear only in services calls.)
However, values in those fields will be indexed, and the
records containing a particular value will be returned from a
keyword search on that value, even if the fields themselves
will not be displayed in summary listings of search results,
or in full records.
In addition, as noted above, those extension fields will
still be retrievable via direct calls to the Person or
Organization service, to retrieve Contact record(s), if any,
for a particular person or organization. At best, placing
the fields more likely to be non-public in an extension
schema is a form of "security through obscurity."
Thinking out loud - this is untested, and hence may not
work, but ... you might restrict access to the resource URL
paths that allow access to Contact records (e.g.
.../Persons/{person ID}/Contacts) only to a particular broad
role, such as a ROLE_MUSEUM_STAFF role, as well as to any
applicable administrator-related roles. Presumably, that
would permit only logged in users with one or more of those
roles assigned to their accounts to access Contact information.
You could then set up an account for a publishing script or
program, perhaps giving it a different role, such as
ROLE_CONTACT_INFO_PUBLISHER, and give it read-only access to
the Contact URL resource paths. That script or program would
then contain its own, configurable or hard-coded, logic for
determining what fields should be published on the web,
internally or externally to your institution.
There is a functionality requirement, post release 1.0, to
facilitate more granular access controls, extending to the record
(resource) level and probably ultimately, to the field
(attribute) level. That might at least indirectly facilitate
the behavior you're describing.
Aron
På vegne af
Aron Roberts
Sendt: 23. juni 2010 16:14
Til: Christopher Pott
Cc: talk@lists.collectionspace.org
Emne: Re: [Talk] employee data in CollectionSpace
On Wed, Jun 23, 2010 at 4:38 AM, Christopher Pott
Christopher.Pott@smk.dk wrote:
Do you have any further words of comfort about the
following points?...
- the ability to add new fields (CV, conferences attended,
qualifications etc.) which I hope we can accomplish via
schema extensions either to the Contact or Person schemas.
Contact records are amenable to schema extension.
- the ability to mark individual fields for internet or intranet
publishing
You can let us know if this response might meet your needs
for this:
through the Person service, you can programmatically
retrieve Person
records and their associated Contact record(s), and extract
data from
selected Contact record fields for re-publishing. As one of many
options, a web application that generates dynamic pages -
using PHP,
ColdFusion, JSP, ASP, etc. - could presumably make these calls
directly to the CollectionSpace services layer.
- support for images (presumeably supported via media snapshot
relationship?)
Interesting. Any record can be related to any other in
CollectionSpace through relationship / relations records, and Media
records are coming in 0.9, so as one option, it might be
possible in
this way to relate, say, a Media record referring to a portrait
photograph to a Person record or a Media record referring to a
photograph of a group at a conference to multiple depicted Peron
records.
I'm unclear on whether it's preferable to organise Persons
via internal fields as Angela suggested, or by relating
Person records within a hierarchy of Organisations (if I've
understood correctly this is also a possibility).
Perhaps others might wish to comment on this ...
Encryption would be necessary for some of our confidential
employee data used by our Administration department. However,
we don't have immediate plans to migrate this to CollectionSpace.
I'd like to soon use a local deployment of CollectionSpace
for trying this out. ie. serving Person data to an intranet
site from which we can implement the ability, via web
services, to update/edit employee details (for test use
only). Should 0.8 be able to handle this?
Yes, with the caveat that the Contact record schema for 0.8 is
rudimentary. Nonetheless, any mechanism you create now for
retrieving
/ editing employee details has a high likelihood - schema changes
notwithstanding - of working 'as is', or with only minor
modification,
when accessing future releases as well.
Aron
/Chris
Developer, Corpus Project
Statens Museum for Kunst (National Gallery of Denmark)
-----Oprindelig meddelelse-----
Fra: aronroberts@gmail.com [mailto:aronroberts@gmail.com]
På vegne af
Aron Roberts
Sendt: 22. juni 2010 18:53
Til: Christopher Pott
Cc: talk@lists.collectionspace.org
Emne: Re: [Talk] employee data in CollectionSpace
Chris wrote:
We have a requirement for storage of some basic data
relating to all
museum employees with the possibility to make (some) of
this data (eg.
phone number, name, department etc.) available to a web site (and
probably some other applications) via a web service.
Would it be appropriate to store this data within
CollectionSpace as
Person Name Authority records?
A followup to the two very interesting messages so far in
this thread:
- Angela's comment on the use of the "Person's occupation" and
"Person's group" fields. - Patrick's preview of future functionality around tagging and
filtering of person authority records, and his comment on securing
personally identifiable information (e.g. identification
of a person
as a "donor").
Yes, it can be appropriate to store basic contact and affiliation
information for museum employees in CollectionSpace.
In the CollectionSpace services layer, there is today a very
rudimentary Contact record, at least a placeholder for future
functionality. There is a many to one relationship
between Contacts
and Person (and Organization) records:
PersonAuthority ==> 0...n Persons
|__ each Person ==> 0..n Contacts
OrganizationAuthority => 0...n Organizations
|__ each Organization ==> 0...n Contacts
These RESTful API documents have been recently updated to
describe
how you can add Contacts to Persons and Organizations, via
the Person
and Organization services:
e+REST+APIs+-+Release+v0.8#PersonServiceRESTAPIs-Releasev0.8-ContactC
RUDLservices
Service+REST+APIs+-+Release+v0.8#OrganizationServiceRESTAPIs-Releasev
0.8-ContactCRUDLservices
There will be full-stack support for adding Contacts
through the UI
in a future release. The current wireframes / designs for this:
Name+Authority
The current Contact schema looks like this:
In 0.8:
y+Schema+-+Limited+for+Release+0.8
(see the "Contact Information" subhead)
For post-1.0 implementation:
y+Schema#NameAuthoritySchema-ContactInformation
There have also been some ambitious suggestions to revise the
'post-1.0' Contact schema above, from modestly to
radically, to make
it even more flexible for today's mix of physical and electronic
address types. There is a JIRA issue for this, which includes a
summary description and pointer to a December 2009
discussion on this
topic with Michael Black of PAHMA and several of our Museum
Informatics folks:
"Revise the Contact info schema"
http://issues.collectionspace.org/browse/CSPACE-836
We very much invite your - ongoing - feedback on the
Contact record
schema, with respect to meeting SMK's needs.
Aron
P.S. It's also my personal hope that we will at some point support
import and export of Contacts in the standard vCard
format, although
this might not be on the 1.0/2.0 roadmap.
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.c
ollectionspace.org
Hi Chris,
At 14:59 +0200 2010-07-02, Christopher Pott wrote:
In the meantime I've used the Person service api
to prototype a basic webpage for creating,
viewing and deleting person details, and it was
a relatively painless experience :-) I look
forward to adding the Contact relations and
trying out some schema extensions in 0.8.
This is thoroughly exciting, as others have also mentioned!
We've long envisioned an ecosystem of auxiliary
applications and utilities - web-based, desktop,
and even mobile, ranging from from quick "one
off" tools to production systems - built on top
of CollectionSpace services.
Your ongoing feedback as you work with the
services is welcomed. This can take the form of
messages to this Talk list and other
CollectionSpace lists, as well as - ideally - in
bug reports and improvement suggestions added
directly to the project's issues list:
http://wiki.collectionspace.org/display/collectionspace/Issue+Tracking
Aron
/Chris
-----Oprindelig meddelelse-----
Fra: Patrick Schmitz [mailto:pschmitz@berkeley.edu]
Sendt: 24. juni 2010 23:26
Til: 'Aron Roberts'; Christopher Pott
Cc: talk@lists.collectionspace.org
Emne: RE: [Talk] employee data in CollectionSpace
Field-level security is planned for a later release, however, we'd have to
create a new class of permissions for "sharing" in this manner. This is
doable, but I'd want to know more about what you are trying to do, in the
hopes that work we did would be more generally reusable.
Another approach is to configure this access through the application layer,
but this would leave a security hole in the services, as Aron mentions
below.
Another possibility would be to group the sensitive data into a single
schema within Contact, and control access to that. In any case, we should
probably talk some more about your requirements.
Thanks, hope this helps -
Patrick
-----Original Message-----
From: talk-bounces@lists.collectionspace.org
[mailto:talk-bounces@lists.collectionspace.org] On Behalf Of
Aron Roberts
Sent: Thursday, June 24, 2010 6:49 AM
To: Christopher Pott
Cc: talk@lists.collectionspace.org
Subject: Re: [Talk] employee data in CollectionSpace
Hi Chris,
On Thu, Jun 24, 2010 at 12:33 AM, Christopher Pott
Christopher.Pott@smk.dk wrote:
Thanks for answering all my questions. There's just one
point I'm still unclear about.....
- the ability to mark individual fields for internet or intranet
publishing
You can let us know if this response might meet your needs
for this:
through the Person service, you can programmatically
retrieve Person
records and their associated Contact record(s), and extract
data from
selected Contact record fields for re-publishing. As one of many
options, a web application that generates dynamic pages -
using PHP,
ColdFusion, JSP, ASP, etc. - could presumably make these calls
directly to the CollectionSpace services layer.
That describes broadly what we'd like to accomplish, but
what I was trying to describe was a detail related to this
scenario - that we may need to allow an employee to mark any
of their own Contact fields as a field which they would allow
to be published internally, externally, niether or both. We
could create yet more fields (via schema extension) to hold
this information but I just wanted to check if there wasn't
already a method in place related to capturing metadata about
a field - in this case the fields visibility within different
web domains.
Others may wish to comment or correct; here are some
initial thoughts regarding your requirement:
The Contact schema - and to my knowledge, schemas for
objects and procedural entities more generally - currently
does not / do not expose any metadata on a per-field basis,
such as the 'permission to publish this field
[internally|externally]' flag you describe.
(Having that is a really interesting idea, by the way.)
If you add fields that you don't wish to have automatically
published, to an extension schema for Contacts, those fields
won't automatically appear in the web UI in a CollectionSpace
system. (To enable those to show up in the UI, you'd also
need to make changes in the App and UI layers; if you don't,
those fields will appear only in services calls.)
However, values in those fields will be indexed, and the
records containing a particular value will be returned from a
keyword search on that value, even if the fields themselves
will not be displayed in summary listings of search results,
or in full records.
In addition, as noted above, those extension fields will
still be retrievable via direct calls to the Person or
Organization service, to retrieve Contact record(s), if any,
for a particular person or organization. At best, placing
the fields more likely to be non-public in an extension
schema is a form of "security through obscurity."
Thinking out loud - this is untested, and hence may not
work, but ... you might restrict access to the resource URL
paths that allow access to Contact records (e.g.
.../Persons/{person ID}/Contacts) only to a particular broad
role, such as a ROLE_MUSEUM_STAFF role, as well as to any
applicable administrator-related roles. Presumably, that
would permit only logged in users with one or more of those
roles assigned to their accounts to access Contact information.
You could then set up an account for a publishing script or
program, perhaps giving it a different role, such as
ROLE_CONTACT_INFO_PUBLISHER, and give it read-only access to
the Contact URL resource paths. That script or program would
then contain its own, configurable or hard-coded, logic for
determining what fields should be published on the web,
internally or externally to your institution.
There is a functionality requirement, post release 1.0, to
facilitate more granular access controls, extending to the record
(resource) level and probably ultimately, to the field
(attribute) level. That might at least indirectly facilitate
the behavior you're describing.
Aron
På vegne af
Aron Roberts
Sendt: 23. juni 2010 16:14
Til: Christopher Pott
Cc: talk@lists.collectionspace.org
Emne: Re: [Talk] employee data in CollectionSpace
On Wed, Jun 23, 2010 at 4:38 AM, Christopher Pott
Christopher.Pott@smk.dk wrote:
Do you have any further words of comfort about the
following points?...
- the ability to add new fields (CV, conferences attended,
qualifications etc.) which I hope we can accomplish via
schema extensions either to the Contact or Person schemas.
Contact records are amenable to schema extension.
- the ability to mark individual fields for internet or intranet
publishing
You can let us know if this response might meet your needs
for this:
through the Person service, you can programmatically
retrieve Person
records and their associated Contact record(s), and extract
data from
selected Contact record fields for re-publishing. As one of many
options, a web application that generates dynamic pages -
using PHP,
ColdFusion, JSP, ASP, etc. - could presumably make these calls
directly to the CollectionSpace services layer.
- support for images (presumeably supported via media snapshot
relationship?)
Interesting. Any record can be related to any other in
CollectionSpace through relationship / relations records, and Media
records are coming in 0.9, so as one option, it might be
possible in
this way to relate, say, a Media record referring to a portrait
photograph to a Person record or a Media record referring to a
photograph of a group at a conference to multiple depicted Peron
records.
I'm unclear on whether it's preferable to organise Persons
via internal fields as Angela suggested, or by relating
Person records within a hierarchy of Organisations (if I've
understood correctly this is also a possibility).
Perhaps others might wish to comment on this ...
Encryption would be necessary for some of our confidential
employee data used by our Administration department. However,
we don't have immediate plans to migrate this to CollectionSpace.
I'd like to soon use a local deployment of CollectionSpace
for trying this out. ie. serving Person data to an intranet
site from which we can implement the ability, via web
services, to update/edit employee details (for test use
only). Should 0.8 be able to handle this?
Yes, with the caveat that the Contact record schema for 0.8 is
rudimentary. Nonetheless, any mechanism you create now for
retrieving
/ editing employee details has a high likelihood - schema changes
notwithstanding - of working 'as is', or with only minor
modification,
when accessing future releases as well.
Aron
/Chris
Developer, Corpus Project
Statens Museum for Kunst (National Gallery of Denmark)
-----Oprindelig meddelelse-----
Fra: aronroberts@gmail.com [mailto:aronroberts@gmail.com]
På vegne af
Aron Roberts
Sendt: 22. juni 2010 18:53
Til: Christopher Pott
Cc: talk@lists.collectionspace.org
Emne: Re: [Talk] employee data in CollectionSpace
Chris wrote:
We have a requirement for storage of some basic data
relating to all
museum employees with the possibility to make (some) of
this data (eg.
phone number, name, department etc.) available to a web site (and
probably some other applications) via a web service.
Would it be appropriate to store this data within
CollectionSpace as
Person Name Authority records?
A followup to the two very interesting messages so far in
this thread:
- Angela's comment on the use of the "Person's occupation" and
"Person's group" fields. - Patrick's preview of future functionality around tagging and
filtering of person authority records, and his comment on securing
personally identifiable information (e.g. identification
of a person
as a "donor").
Yes, it can be appropriate to store basic contact and affiliation
information for museum employees in CollectionSpace.
In the CollectionSpace services layer, there is today a very
rudimentary Contact record, at least a placeholder for future
functionality. There is a many to one relationship
between Contacts
and Person (and Organization) records:
PersonAuthority ==> 0...n Persons
|__ each Person ==> 0..n Contacts
OrganizationAuthority => 0...n Organizations
|__ each Organization ==> 0...n Contacts
These RESTful API documents have been recently updated to
describe
how you can add Contacts to Persons and Organizations, via
the Person
and Organization services:
e+REST+APIs+-+Release+v0.8#PersonServiceRESTAPIs-Releasev0.8-ContactC
RUDLservices
Service+REST+APIs+-+Release+v0.8#OrganizationServiceRESTAPIs-Releasev
0.8-ContactCRUDLservices
There will be full-stack support for adding Contacts
through the UI
in a future release. The current wireframes / designs for this:
Name+Authority
The current Contact schema looks like this:
In 0.8:
y+Schema+-+Limited+for+Release+0.8
(see the "Contact Information" subhead)
For post-1.0 implementation:
y+Schema#NameAuthoritySchema-ContactInformation
There have also been some ambitious suggestions to revise the
'post-1.0' Contact schema above, from modestly to
radically, to make
it even more flexible for today's mix of physical and electronic
address types. There is a JIRA issue for this, which includes a
summary description and pointer to a December 2009
discussion on this
topic with Michael Black of PAHMA and several of our Museum
Informatics folks:
"Revise the Contact info schema"
http://issues.collectionspace.org/browse/CSPACE-836
We very much invite your - ongoing - feedback on the
Contact record
schema, with respect to meeting SMK's needs.
Aron
P.S. It's also my personal hope that we will at some point support
import and export of Contacts in the standard vCard
format, although
this might not be on the 1.0/2.0 roadmap.
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.c
ollectionspace.org