Hi Michael,
It looks like we are on the same page.  I like your idea of a
temporary template switch. Wouldn't it also be cool to have a template
in which all empty fields were hidden, kind of like a data list view?
Maybe not, I'm not sure.

Create New using Coin Template?

I would probably set a hidden field in the template. Then after
selecting "Create new form Coin Template", the user doesn't have to also
select, for example, objectType to be Coin. I am guessing that this
would forgo the opportunity to change the type in the future. I am also
guessing that the user would rather skip the extra step of selecting the
type, than to be able to change the type. It seams, for the most part,
that if the object is a Coin it will always be a Coin.

realize that an object is of a certain type

I had proposed the collection attribute as the one to determine the
template to use, and you are proposing the objectName. What if we were
to use an objectType attribute?  Or better yet: we would be able to
configure which attribute to use to determine the template. So then, it
would be a cascading defaults effect.
If template attribute selector is set in the config, use that, if not,
use the objectType attribute, if that is blank use the default template.
What do you think?

Chris Thompson

On 04/14/2012 11:00 AM, talk-request@lists.collectionspace.org wrote:

Great discussion - thanks you guys.

Suppose we just had support in a template to pre-fill certain fields with
certain default values when you create a new object. Then, by virtue of
using the template, it would set whichever field you wanted (collection,
objectType, etc.) to the value you wanted. Would that be useful for what you
are talking about? This is something that has otherwise been requested, so
it might we worth exploring anyway.

In any case, I was assuming that we (services) would have to store the name
of the template in a specific field in the core schema (a small schema that
is common across all our document types (all records, procedures, etc.)).
So, even if you cannot choose a certain cataloging field-value as indicating
a certain template, the mere act of creating the object with some template
will make that template stick. Import could also set the template value, if
desired.

However, I am still curious about the case of someone creating objects as
part of a specific workflow like Inventory, or when an Intern is doing basic
data entry. I understood that they would use a template to speed (or
simplify) the process, but that later on, someone else would do real
cataloging and would not want to use the Inventory or Intern-entry template.
This is the case in which I assumed we'd have to change the template used.

My question: Is this latter use-case an issue? Did I misunderstand the need
around this? I would of course be much happier with the simpler model that
you get the template you used to create something. However, once we can give
users the option to view an object with a different template (than it was
created with), it should not be much more work to (optionally) save that as
the new default template.

One more question: Making this work for Cataloging (CollectionObjects) is no
more or less work than making it work for all procedures. Am assuming that
there might be at least some use for showing other things like Intakes,
Loans, Media, etc. with different templates. Would you agree? Or, should we
specifically restrict this to CollectionObject/Cataloging?

And a final question: have heard requests for specific permissions on
templates, so that the use of each template be constrained to certain roles.
This will somewhat complicate a number of things (user-admin to control the
roles using a template, the CreateNew page that would have to filter the
list of templates for the current user, and any UI to choose other templates
for viewing). How important is this aspect of templates (controlling use by
role)?

Thanks - Patrick

From: talk-bounces@lists.collectionspace.org
[mailto:talk-bounces@lists.collectionspace.org] On Behalf Of Chris Thompson
Sent: Saturday, April 14, 2012 10:19 AM
To: Michael T. Black
Cc: CollectionSpace Talk List
Subject: Re: [Talk] Talk Digest, Vol 32, Issue 16

Hi Michael,
It looks like we are on the same page.  I like your idea of a temporary
template switch. Wouldn't it also be cool to have a template in which all
empty fields were hidden, kind of like a data list view? Maybe not, I'm not
sure.

New using Coin Template?

I would probably set a hidden field in the template. Then after selecting
"Create new form Coin Template", the user doesn't have to also select, for
example, objectType to be Coin. I am guessing that this would forgo the
opportunity to change the type in the future. I am also guessing that the
user would rather skip the extra step of selecting the type, than to be able
to change the type. It seams, for the most part, that if the object is a
Coin it will always be a Coin.

realize that an object is of a certain type

I had proposed the collection attribute as the one to determine the template
to use, and you are proposing the objectName. What if we were to use an
objectType attribute?  Or better yet: we would be able to configure which
attribute to use to determine the template. So then, it would be a cascading
defaults effect.
If template attribute selector is set in the config, use that, if not, use
the objectType attribute, if that is blank use the default template. What do
you think?

Chris Thompson

On 04/14/2012 11:00 AM, talk-request@lists.collectionspace.org wrote:

Message: 3

Date: Fri, 13 Apr 2012 14:25:39 -0700

From: Michael T. Black  mailto:mtblack@berkeley.edu mtblack@berkeley.edu

To: Michael T. Black  mailto:mtblack@berkeley.edu mtblack@berkeley.edu

Cc: CollectionSpace Talk List  mailto:talk@lists.collectionspace.org
talk@lists.collectionspace.org

Subject: Re: [Talk] Edit Cataloging Templates

Message-ID:  mailto:68B1DD3A-013C-4423-9873-8BDF16459F6A@berkeley.edu
68B1DD3A-013C-4423-9873-8BDF16459F6A@berkeley.edu

Content-Type: text/plain; charset=us-ascii

Hi Patrick,

Concerning the changing of templates for an object: I would like to

see the selected template for an object be something that generally isn't
changed once set, but I also don't want to be limited to viewing the
object's data in only that template.  I'd be happier having a coin's
information displayed using the coin template (which for PAHMA would contain
all of the fields that are commonly used for an object type, but which would
not contain all of the fields that could ever be used for an object type),
and if you're a curator or registrar who wants/needs to see absolutely
everything about an object, you can temporarily (i.e., for this user
during this session) switch to viewing the data in another layout/template.

Concerning selecting the appropriate template for an object: I

wouldn't use collection, at least not for PAHMA, and I can't think of any
other pre-existing field in the PAHMA implementation that would work for
automatically assigning templates.  For new cataloging, of course, the
registrar or other cataloger would manually select the appropriate template.
For existing records, I fear that template selection will probably end up
being at least semi-manual.

Regarding Chris' example of creating a "Coin" record: How does

CSpace know that you're creating a coin record other than Create New using
Coin Template?  I think I'm missing something here, unless he's thinking of
a different interface for creating new cataloging records.  For existing
records that aren't [yet] assigned a template, I think it would be an
awfully handy thing to have CSpace somehow realize that an object is of a
certain type (perhaps via the objectName mapped against an ontology?)  and
then suggest (or provisionally assign) the most appropriate template.  And
if there's no appropriate template, leave it assigned to the default
template.

Michael

We have been following this discussion with interest. The templates-issue is not really a cardinal point to us. At present we only use templates in Cataloguing and I don't think we will use it in other procedures - but possibly in Person Authority records if possible.

Currently we use templates for overall object types (not to be confused with the Object Name which can be seen as a sub-category of the object type) for various groups of works of art (painting, sculpture, drawing, graphics, photography, installation art, audio-visual art, artist's books, casts, and casts' originals) and in one instance supporting a workflow for in-loan (visiting works of art). The object type 'field' is not visible in the UI but appears as an overall header.

To us it is not a requirement to be able to switch between template view and the full cataloguing record. We would expect that a record created in a template will always open in that same template - but we do not mind the flexibility, and I can see a point in using templates in various workflows without having to view the full record. To us that would be a 'nice to have', and not a requirement.

Regarding permissions in relation to templates we have no special requirements. Today anyone with edit rights can create new and edit in all templates.

Cheers,
Kim

Beat regards,

Kim Brasen
Curator

T +45 3374 8460

Statens Museum for Kunst
Sølvgade 48-50
DK-1307 København K

T +45 3374 8494
F +45 3374 8404
smk.dkhttp://smk.dk/

[cid:image002.jpg@01CD1EE4.0E0667D0]

Fra: talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org] På vegne af Patrick Schmitz
Sendt: 15. april 2012 20:39
Til: 'Chris Thompson'; 'Michael T. Black'
Cc: 'CollectionSpace Talk List'
Emne: Re: [Talk] Talk Digest, Vol 32, Issue 16

Great discussion - thanks you guys.

Suppose we just had support in a template to pre-fill certain fields with certain default values when you create a new object. Then, by virtue of using the template, it would set whichever field you wanted (collection, objectType, etc.) to the value you wanted. Would that be useful for what you are talking about? This is something that has otherwise been requested, so it might we worth exploring anyway.

In any case, I was assuming that we (services) would have to store the name of the template in a specific field in the core schema (a small schema that is common across all our document types (all records, procedures, etc.)). So, even if you cannot choose a certain cataloging field-value as indicating a certain template, the mere act of creating the object with some template will make that template stick. Import could also set the template value, if desired.

However, I am still curious about the case of someone creating objects as part of a specific workflow like Inventory, or when an Intern is doing basic data entry. I understood that they would use a template to speed (or simplify) the process, but that later on, someone else would do real cataloging and would not want to use the Inventory or Intern-entry template. This is the case in which I assumed we'd have to change the template used.

My question: Is this latter use-case an issue? Did I misunderstand the need around this? I would of course be much happier with the simpler model that you get the template you used to create something. However, once we can give users the option to view an object with a different template (than it was created with), it should not be much more work to (optionally) save that as the new default template.

One more question: Making this work for Cataloging (CollectionObjects) is no more or less work than making it work for all procedures. Am assuming that there might be at least some use for showing other things like Intakes, Loans, Media, etc. with different templates. Would you agree? Or, should we specifically restrict this to CollectionObject/Cataloging?

And a final question: have heard requests for specific permissions on templates, so that the use of each template be constrained to certain roles. This will somewhat complicate a number of things (user-admin to control the roles using a template, the CreateNew page that would have to filter the list of templates for the current user, and any UI to choose other templates for viewing). How important is this aspect of templates (controlling use by role)?

Thanks - Patrick

From: talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of Chris Thompson
Sent: Saturday, April 14, 2012 10:19 AM
To: Michael T. Black
Cc: CollectionSpace Talk List
Subject: Re: [Talk] Talk Digest, Vol 32, Issue 16
Hi Michael,
It looks like we are on the same page.  I like your idea of a temporary template switch. Wouldn't it also be cool to have a template in which all empty fields were hidden, kind of like a data list view? Maybe not, I'm not sure.

I would probably set a hidden field in the template. Then after selecting "Create new form Coin Template", the user doesn't have to also select, for example, objectType to be Coin. I am guessing that this would forgo the opportunity to change the type in the future. I am also guessing that the user would rather skip the extra step of selecting the type, than to be able to change the type. It seams, for the most part, that if the object is a Coin it will always be a Coin.

I had proposed the collection attribute as the one to determine the template to use, and you are proposing the objectName. What if we were to use an objectType attribute?  Or better yet: we would be able to configure which attribute to use to determine the template. So then, it would be a cascading defaults effect.
If template attribute selector is set in the config, use that, if not, use the objectType attribute, if that is blank use the default template. What do you think?

Chris Thompson

On 04/14/2012 11:00 AM, talk-request@lists.collectionspace.orgmailto:talk-request@lists.collectionspace.org wrote:

Message: 3

Date: Fri, 13 Apr 2012 14:25:39 -0700

From: Michael T. Black mtblack@berkeley.edumailto:mtblack@berkeley.edu

To: Michael T. Black mtblack@berkeley.edumailto:mtblack@berkeley.edu

Cc: CollectionSpace Talk List talk@lists.collectionspace.orgmailto:talk@lists.collectionspace.org

Subject: Re: [Talk] Edit Cataloging Templates

Message-ID: 68B1DD3A-013C-4423-9873-8BDF16459F6A@berkeley.edumailto:68B1DD3A-013C-4423-9873-8BDF16459F6A@berkeley.edu

Content-Type: text/plain; charset=us-ascii

Hi Patrick,

  Concerning the changing of templates for an object: I would like to see the selected template for an object be something that generally isn't changed once set, but I also don't want to be limited to viewing the object's data in only that template.  I'd be happier having a coin's information displayed using the coin template (which for PAHMA would contain all of the fields that are commonly used for an object type, but which would not contain all of the fields that could *ever* be used for an object type), and if you're a curator or registrar who wants/needs to see absolutely everything about an object, you can *temporarily* (i.e., for this user during this session) switch to viewing the data in another layout/template.



  Concerning selecting the appropriate template for an object: I wouldn't use collection, at least not for PAHMA, and I can't think of any other pre-existing field in the PAHMA implementation that would work for automatically assigning templates.  For new cataloging, of course, the registrar or other cataloger would manually select the appropriate template.  For existing records, I fear that template selection will probably end up being at least semi-manual.



  Regarding Chris' example of creating a "Coin" record: How does CSpace know that you're creating a coin record other than Create New using Coin Template?  I think I'm missing something here, unless he's thinking of a different interface for creating new cataloging records.  For existing records that aren't [yet] assigned a template, I think it would be an awfully handy thing to have CSpace somehow realize that an object is of a certain type (perhaps via the objectName mapped against an ontology?)  and then suggest (or provisionally assign) the most appropriate template.  And if there's no appropriate template, leave it assigned to the default template.

Michael