Quick question for implementers and interested parties -

The keyword search box in the upper right and find/edit screen currently
has an option called "all record types." Currently, this only searches
across procedural records (including cataloging), not authorities. We now
have the ability to add authority terms into this "all" search, but I would
like to know if that's something folks want before we do the work.

Please let me know your opinions.

Best regards,
Megan

--
Megan Forbes
Collection Manager

Museum of the Moving Image
36-01 35 Avenue  Astoria, NY 11106
movingimage.us  718 777 6800
Direct 718 777 6834

Megan, et al.,

I am following up on some older posts about finding the current storage
location of a collection object,  Please refer to CSPACE-5459 for more
details

FIND CURRENT LOCATION

At a meeting yesterday, we reviewed alternatives and have tentatively
selected an implementation that "denormalizes" storage location data to
allow easy access to the current location of an object (in the UI, for
reporting, etc.).

I have been asked to report on this suggestion and gather feedback. We'd
like to to ensure that the various use cases are supported.

In sum:

• One or more fields would be added to the core collection object
  indicating the current location of the object.
• Specifically, the storage authority refName of the object's location
  would be stored, read-only, perhaps with a pointer to the (latest) LMI
  record which licenses that assertion (other data elements, such as the
  locationdate, might be included as well).
• The displayName corresponding to this read-only refName value would
  appear in the cataloging object UI.
• This authority term would also show up in the list of Terms Used in the
  right sidebar.
• Would there be a need to pivot from the value shown to the corresponding
  LMI and/or storage location?
• When looking at the Movement tab for a cataloging record, should the
  fact that one of the LMI records shown is the current location be
  indicated somehow?

While the details of the implementation remain to be worked out, clearly
it is the services layer that will be responsible for seeing that these
values get updated appropriately.

Considering how this proposal will affect IMPORT and updates via the REST
API, the current thinking is that a separate batch process will be
provided that can be kicked off (manually) after the relevant records are
loaded (catalogobject, LMI, and relations). Trying to do otherwise might
be inefficient and could unnecessarily constrain deployers in how they
load records.

LOCATION MOVEMENT

At the same time as you consider this proposal, we would like to call your
attention to a related use case, currrently unsupported, that may
complicate our choices.

see also:
http://wiki.collectionspace.org/pages/viewpage.action?pageId=95879255
http://wiki.collectionspace.org/display/deploy/Crates+and+other+mobile+containers
http://wiki.collectionspace.org/display/deploy/PAHMA+Storage+Location+data+mapping
some of which are pretty much "legacy documents" at this point)

We had attempted earlier to provided initial support for "movable
locations" -- a flag was added to the storage location schema to indicate
that the location was "movable", and this value was exposed as a check
box.  Movable locations ("crates", to use the PAHMA terminology) are
always located within another storage location, and the idea was to use
the BT/NT hierarchy to indicate the location of a crate.  This
implementation failed to work for PAHMA. The alternative was to make
"crates" a separate authority and to customize the LMI record to show both
a "standard" storage location and an optional crate.

You can see where this is going: if the implementation of "denormalized
locations" goes ahead as suggested above, would it be wise to consider the
handling of movable locations now as well?  If this feature is likely to
be needed in most cases (see wiki... for a discussion of use cases), then
doing the schema, UI, and services changes to support this at the same
time as locations are denormalized makes sense.  (The alternative, of
course, is to make movable containers a customization, as it is now).

Alas, I have to attach my standard dislaimer to this message:

"Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le
loisir de la faire plus courte!" -- Pascal

Regards,

John

read only authority refName in UI
show up in terms used?
able to pivot from UI?
is it enough to just go to the movement tab to see this?
(CRH: we've been encouraging people to stay on the cataloging tab)
mention crates

use an event handler?

batch process to update current location after IMPORT, to verify/update
locations after other maintenance.

Callable from an event handler

send quick note to Megan about reports...

(Trying again, this time with a subject line and better editing! Please
ignore previous post with my apologies!)

Megan, et al.,

I am following up on some older posts about finding the current storage
location of a collection object,  Please refer to CSPACE-5459 for more
details.

FINDING THE CURRENT LOCATION OF AND OBJECT

At a meeting yesterday, we reviewed alternatives and have tentatively
selected an implementation that "denormalizes" storage location data to
allow easy access to the current location of an object (in the UI, for
reporting, etc.).

I have been asked to report on this suggestion and gather feedback. We'd
like to to ensure that the various use cases are supported.

In sum:

• One or more fields would be added to the core collection object
  indicating the current location of the object.
• Specifically, the storage authority refName of the object's location
  would be stored, read-only, perhaps with a pointer to the (latest) LMI
  record which licenses that assertion (other data elements, such as the
  locationdate, might be included as well).
• The displayName corresponding to this read-only refName value would
  appear in the cataloging object UI.
• This authority term would also show up in the list of Terms Used in the
  right sidebar.
• Would there be a need to pivot from the value shown to the corresponding
  LMI and/or storage location?
• When looking at the Movement tab for a cataloging record, should the
  fact that one of the LMI records shown is the current location be
  indicated somehow?

While the details of the implementation remain to be worked out, clearly
it is the services layer that will be responsible for seeing that these
values get updated appropriately.

Considering how this proposal will affect IMPORT and updates via the REST
API, the current thinking is that a separate batch process will be
provided that can be kicked off (manually) after the relevant records are
loaded (catalogobject, LMI, and relations). Trying to do otherwise might
be inefficient and could unnecessarily constrain deployers in how they
load records.

MOVABLE LOCATIONS

At the same time as you consider this proposal, we would like to call your
attention to a related use case, currrently unsupported, that may
complicate our choices.

see also:
http://wiki.collectionspace.org/pages/viewpage.action?pageId=95879255
http://wiki.collectionspace.org/display/deploy/Crates+and+other+mobile+containers
http://wiki.collectionspace.org/display/deploy/PAHMA+Storage+Location+data+mapping
some of which are pretty much "legacy documents" at this point)

We had attempted earlier to provided initial support for "movable
locations" -- a flag was added to the storage location schema to indicate
that the location was "movable", and this value was exposed as a check
box.  Movable locations ("crates", to use the PAHMA terminology) are
always located within another storage location, and the idea was to use
the BT/NT hierarchy to indicate the location of a crate.  This
implementation failed to work for PAHMA. The alternative was to make
"crates" a separate authority and to customize the LMI record to show both
a "standard" storage location and an optional crate.

You can see where this is going: if the implementation of "denormalized
locations" goes ahead as suggested above, would it be wise to consider the
handling of movable locations now as well?  If this feature is likely to
be needed in most cases (see wiki... for a discussion of use cases), then
doing the schema, UI, and services changes to support this at the same
time as locations are denormalized makes sense.  (The alternative, of
course, is to make movable containers a customization, as it is now).

Alas, I have to attach my standard dislaimer to this message:

"Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le
loisir de la faire plus courte!" -- Pascal

Regards,

John

Based on the outcome of our UCB meeting on this topic yesterday afternoon, I
just added four development sub-tasks (with time estimates) to the
CSPACE-5459 issue.

-----Original Message-----
From: Talk [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of
jblowe@berkeley.edu
Sent: Friday, November 16, 2012 8:29 AM
To: Megan Forbes
Cc: CollectionSpace Talk List
Subject: [Talk] (no subject)

Megan, et al.,

I am following up on some older posts about finding the current storage
location of a collection object,  Please refer to CSPACE-5459 for more
details

FIND CURRENT LOCATION

At a meeting yesterday, we reviewed alternatives and have tentatively
selected an implementation that "denormalizes" storage location data to
allow easy access to the current location of an object (in the UI, for
reporting, etc.).

I have been asked to report on this suggestion and gather feedback. We'd
like to to ensure that the various use cases are supported.

In sum:

• One or more fields would be added to the core collection object indicating
  the current location of the object.
• Specifically, the storage authority refName of the object's location would
  be stored, read-only, perhaps with a pointer to the (latest) LMI record
  which licenses that assertion (other data elements, such as the
  locationdate, might be included as well).
• The displayName corresponding to this read-only refName value would appear
  in the cataloging object UI.
• This authority term would also show up in the list of Terms Used in the
  right sidebar.
• Would there be a need to pivot from the value shown to the corresponding
  LMI and/or storage location?
• When looking at the Movement tab for a cataloging record, should the fact
  that one of the LMI records shown is the current location be indicated
  somehow?

While the details of the implementation remain to be worked out, clearly it
is the services layer that will be responsible for seeing that these values
get updated appropriately.

Considering how this proposal will affect IMPORT and updates via the REST
API, the current thinking is that a separate batch process will be provided
that can be kicked off (manually) after the relevant records are loaded
(catalogobject, LMI, and relations). Trying to do otherwise might be
inefficient and could unnecessarily constrain deployers in how they load
records.

LOCATION MOVEMENT

At the same time as you consider this proposal, we would like to call your
attention to a related use case, currrently unsupported, that may complicate
our choices.

see also:
http://wiki.collectionspace.org/pages/viewpage.action?pageId=95879255
http://wiki.collectionspace.org/display/deploy/Crates+and+other+mobile+conta
iners
http://wiki.collectionspace.org/display/deploy/PAHMA+Storage+Location+data+m
apping
some of which are pretty much "legacy documents" at this point)

We had attempted earlier to provided initial support for "movable locations"
-- a flag was added to the storage location schema to indicate that the
location was "movable", and this value was exposed as a check box.  Movable
locations ("crates", to use the PAHMA terminology) are always located within
another storage location, and the idea was to use
the BT/NT hierarchy to indicate the location of a crate.  This
implementation failed to work for PAHMA. The alternative was to make
"crates" a separate authority and to customize the LMI record to show both a
"standard" storage location and an optional crate.

You can see where this is going: if the implementation of "denormalized
locations" goes ahead as suggested above, would it be wise to consider the
handling of movable locations now as well?  If this feature is likely to be
needed in most cases (see wiki... for a discussion of use cases), then doing
the schema, UI, and services changes to support this at the same time as
locations are denormalized makes sense.  (The alternative, of course, is to
make movable containers a customization, as it is now).

Alas, I have to attach my standard dislaimer to this message:

"Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de
la faire plus courte!" -- Pascal

Regards,

John

read only authority refName in UI
show up in terms used?
able to pivot from UI?
is it enough to just go to the movement tab to see this?
(CRH: we've been encouraging people to stay on the cataloging tab) mention
crates

use an event handler?

batch process to update current location after IMPORT, to verify/update
locations after other maintenance.

Callable from an event handler

send quick note to Megan about reports...

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace
.org

Hi Megan,

At SMK we agree with PAHMA. Excluding authority terms from "all record types" would probably confuse our users.

Cheers,
Kim

Fra: Talk [mailto:talk-bounces@lists.collectionspace.org] På vegne af Michael T. Black
Sendt: 16. november 2012 15:53
Til: Megan Forbes
Cc: CollectionSpace Talk List
Emne: Re: [Talk] Search across all record types

Hi Megan,

                  We at PAHMA would really like to have "all record types" include authority terms.  Having authority terms excluded continues to confound users.

Thanks,

Michael

On Nov 16, 2012, at 8:40 AM, Megan Forbes <mforbes@movingimage.usmailto:mforbes@movingimage.us> wrote:

Quick question for implementers and interested parties -

The keyword search box in the upper right and find/edit screen currently has an option called "all record types." Currently, this only searches across procedural records (including cataloging), not authorities. We now have the ability to add authority terms into this "all" search, but I would like to know if that's something folks want before we do the work.

Please let me know your opinions.

Best regards,
Megan

--
Megan Forbes
Collection Manager

Museum of the Moving Image
36-01 35 Avenue  Astoria, NY 11106
movingimage.ushttp://movingimage.us/  718 777 6800
Direct 718 777 6834

Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Hi, thanks for posting your deliberations, we're happy to see this issue being discussed again.

We've discussed this again, and I think we're on the same page regarding your comments below. We like the idea of adding a reference to the current location to the collection object record - but why not go further and add the whole 'Location information' group to the collectionobject? And why duplicate it in the Movement procedure?

Currently, the Location/Movement procedure involves establishing a 'current location' and then later moving an object FROM this location. Logically, we can't see a problem with this, but in practice we get confused all over again every time we try to work with the records. Having Location and Movement share the same procedure seems to be what causes the confusion.

We think many problems could be solved if we treated Movement as the key functionality of the procedure (ignoring Inventory for now) and move the 'Location group' of fields to the Cataloguing object. With this approach one would then use the Movement procedure to move an object TO a 'destination location' (which would be new field in the Movement group).

Our justification for this is as follows:
*The naming of 'Current location' hints strongly that the current approach is confused. The name makes sense when creating the record, but not when viewing movement history. The way we see it, that's because it's really the 'destination location of a previous movement' AND only sometimes the 'current location'.
*'Normal location' is currently resaved for every movement, but it should be a fairly static property of the collection object rather than of a movement.
*'Location date' is the 'removal date of a previous movement' AND sometimes the 'start date of the current location'.

Crucially, for us, the current approach also makes it impossible to plan moves in the future. If we could create 'movement To' records independent of current location, this would help.

-----Oprindelig meddelelse-----
Fra: Talk [mailto:talk-bounces@lists.collectionspace.org] På vegne af jblowe@berkeley.edu
Sendt: 16. november 2012 17:29
Til: Megan Forbes
Cc: CollectionSpace Talk List
Emne: [Talk] (no subject)

Megan, et al.,

I am following up on some older posts about finding the current storage
location of a collection object,  Please refer to CSPACE-5459 for more
details

FIND CURRENT LOCATION

At a meeting yesterday, we reviewed alternatives and have tentatively
selected an implementation that "denormalizes" storage location data to
allow easy access to the current location of an object (in the UI, for
reporting, etc.).

I have been asked to report on this suggestion and gather feedback. We'd
like to to ensure that the various use cases are supported.

In sum:

• One or more fields would be added to the core collection object
  indicating the current location of the object.
• Specifically, the storage authority refName of the object's location
  would be stored, read-only, perhaps with a pointer to the (latest) LMI
  record which licenses that assertion (other data elements, such as the
  locationdate, might be included as well).
• The displayName corresponding to this read-only refName value would
  appear in the cataloging object UI.
• This authority term would also show up in the list of Terms Used in the
  right sidebar.
• Would there be a need to pivot from the value shown to the corresponding
  LMI and/or storage location?
• When looking at the Movement tab for a cataloging record, should the
  fact that one of the LMI records shown is the current location be
  indicated somehow?

While the details of the implementation remain to be worked out, clearly
it is the services layer that will be responsible for seeing that these
values get updated appropriately.

Considering how this proposal will affect IMPORT and updates via the REST
API, the current thinking is that a separate batch process will be
provided that can be kicked off (manually) after the relevant records are
loaded (catalogobject, LMI, and relations). Trying to do otherwise might
be inefficient and could unnecessarily constrain deployers in how they
load records.

LOCATION MOVEMENT

At the same time as you consider this proposal, we would like to call your
attention to a related use case, currrently unsupported, that may
complicate our choices.

see also:
http://wiki.collectionspace.org/pages/viewpage.action?pageId=95879255
http://wiki.collectionspace.org/display/deploy/Crates+and+other+mobile+containers
http://wiki.collectionspace.org/display/deploy/PAHMA+Storage+Location+data+mapping
some of which are pretty much "legacy documents" at this point)

We had attempted earlier to provided initial support for "movable
locations" -- a flag was added to the storage location schema to indicate
that the location was "movable", and this value was exposed as a check
box.  Movable locations ("crates", to use the PAHMA terminology) are
always located within another storage location, and the idea was to use
the BT/NT hierarchy to indicate the location of a crate.  This
implementation failed to work for PAHMA. The alternative was to make
"crates" a separate authority and to customize the LMI record to show both
a "standard" storage location and an optional crate.

You can see where this is going: if the implementation of "denormalized
locations" goes ahead as suggested above, would it be wise to consider the
handling of movable locations now as well?  If this feature is likely to
be needed in most cases (see wiki... for a discussion of use cases), then
doing the schema, UI, and services changes to support this at the same
time as locations are denormalized makes sense.  (The alternative, of
course, is to make movable containers a customization, as it is now).

Alas, I have to attach my standard dislaimer to this message:

"Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le
loisir de la faire plus courte!" -- Pascal

Regards,

John

read only authority refName in UI
show up in terms used?
able to pivot from UI?
is it enough to just go to the movement tab to see this?
(CRH: we've been encouraging people to stay on the cataloging tab)
mention crates

use an event handler?

batch process to update current location after IMPORT, to verify/update
locations after other maintenance.

Callable from an event handler

send quick note to Megan about reports...

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

....sorry, to answer your specific questions....

• Would there be a need to pivot from the value shown to the corresponding
  LMI and/or storage location?

Isn't this the functionality you'd get via the terms list in the right sidebar? That would be enough for us I think.

• When looking at the Movement tab for a cataloging record, should the
  fact that one of the LMI records shown is the current location be
  indicated somehow?

Yes, if current location and movement must be together, then highlighted row would be nice

The 'moveable locations' issue is not a requirement we share. But if you want an opinion, we would prefer an implementation would allow some flagged 'mobile' locations within the location authority hierarchy which were permitted to be moved around by users within that hierarchy.

If that can't be made to work then a local extension to the movement record (or preferably, in the future, the collectionobject record) where a secondary location could be added, but we don't think this would be the correct solution for a core behaviour.

Regards,
Chris on behalf of team at SMK

-----Oprindelig meddelelse-----
Fra: Talk [mailto:talk-bounces@lists.collectionspace.org] På vegne af jblowe@berkeley.edu
Sendt: 16. november 2012 17:29
Til: Megan Forbes
Cc: CollectionSpace Talk List
Emne: [Talk] (no subject)

Megan, et al.,

I am following up on some older posts about finding the current storage
location of a collection object,  Please refer to CSPACE-5459 for more
details

FIND CURRENT LOCATION

At a meeting yesterday, we reviewed alternatives and have tentatively
selected an implementation that "denormalizes" storage location data to
allow easy access to the current location of an object (in the UI, for
reporting, etc.).

I have been asked to report on this suggestion and gather feedback. We'd
like to to ensure that the various use cases are supported.

In sum:

• One or more fields would be added to the core collection object
  indicating the current location of the object.
• Specifically, the storage authority refName of the object's location
  would be stored, read-only, perhaps with a pointer to the (latest) LMI
  record which licenses that assertion (other data elements, such as the
  locationdate, might be included as well).
• The displayName corresponding to this read-only refName value would
  appear in the cataloging object UI.
• This authority term would also show up in the list of Terms Used in the
  right sidebar.
• Would there be a need to pivot from the value shown to the corresponding
  LMI and/or storage location?
• When looking at the Movement tab for a cataloging record, should the
  fact that one of the LMI records shown is the current location be
  indicated somehow?

While the details of the implementation remain to be worked out, clearly
it is the services layer that will be responsible for seeing that these
values get updated appropriately.

Considering how this proposal will affect IMPORT and updates via the REST
API, the current thinking is that a separate batch process will be
provided that can be kicked off (manually) after the relevant records are
loaded (catalogobject, LMI, and relations). Trying to do otherwise might
be inefficient and could unnecessarily constrain deployers in how they
load records.

LOCATION MOVEMENT

At the same time as you consider this proposal, we would like to call your
attention to a related use case, currrently unsupported, that may
complicate our choices.

see also:
http://wiki.collectionspace.org/pages/viewpage.action?pageId=95879255
http://wiki.collectionspace.org/display/deploy/Crates+and+other+mobile+containers
http://wiki.collectionspace.org/display/deploy/PAHMA+Storage+Location+data+mapping
some of which are pretty much "legacy documents" at this point)

We had attempted earlier to provided initial support for "movable
locations" -- a flag was added to the storage location schema to indicate
that the location was "movable", and this value was exposed as a check
box.  Movable locations ("crates", to use the PAHMA terminology) are
always located within another storage location, and the idea was to use
the BT/NT hierarchy to indicate the location of a crate.  This
implementation failed to work for PAHMA. The alternative was to make
"crates" a separate authority and to customize the LMI record to show both
a "standard" storage location and an optional crate.

You can see where this is going: if the implementation of "denormalized
locations" goes ahead as suggested above, would it be wise to consider the
handling of movable locations now as well?  If this feature is likely to
be needed in most cases (see wiki... for a discussion of use cases), then
doing the schema, UI, and services changes to support this at the same
time as locations are denormalized makes sense.  (The alternative, of
course, is to make movable containers a customization, as it is now).

Alas, I have to attach my standard dislaimer to this message:

"Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le
loisir de la faire plus courte!" -- Pascal

Regards,

John

read only authority refName in UI
show up in terms used?
able to pivot from UI?
is it enough to just go to the movement tab to see this?
(CRH: we've been encouraging people to stay on the cataloging tab)
mention crates

use an event handler?

batch process to update current location after IMPORT, to verify/update
locations after other maintenance.

Callable from an event handler

send quick note to Megan about reports...

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

One more thing came up today whilst migrating Inventory data - we seem to have the same issue with "next inventory date" and "inventory frequency" as we do with "current location", in that it's required to search by date through all related location/movement/inventory records for the most recent record containing the data.

/Chris

-----Oprindelig meddelelse-----
Fra: Talk [mailto:talk-bounces@lists.collectionspace.org] På vegne af jblowe@berkeley.edu
Sendt: 16. november 2012 17:29
Til: Megan Forbes
Cc: CollectionSpace Talk List
Emne: [Talk] (no subject)

Megan, et al.,

I am following up on some older posts about finding the current storage
location of a collection object,  Please refer to CSPACE-5459 for more
details

FIND CURRENT LOCATION

At a meeting yesterday, we reviewed alternatives and have tentatively
selected an implementation that "denormalizes" storage location data to
allow easy access to the current location of an object (in the UI, for
reporting, etc.).

I have been asked to report on this suggestion and gather feedback. We'd
like to to ensure that the various use cases are supported.

In sum:

• One or more fields would be added to the core collection object
  indicating the current location of the object.
• Specifically, the storage authority refName of the object's location
  would be stored, read-only, perhaps with a pointer to the (latest) LMI
  record which licenses that assertion (other data elements, such as the
  locationdate, might be included as well).
• The displayName corresponding to this read-only refName value would
  appear in the cataloging object UI.
• This authority term would also show up in the list of Terms Used in the
  right sidebar.
• Would there be a need to pivot from the value shown to the corresponding
  LMI and/or storage location?
• When looking at the Movement tab for a cataloging record, should the
  fact that one of the LMI records shown is the current location be
  indicated somehow?

While the details of the implementation remain to be worked out, clearly
it is the services layer that will be responsible for seeing that these
values get updated appropriately.

Considering how this proposal will affect IMPORT and updates via the REST
API, the current thinking is that a separate batch process will be
provided that can be kicked off (manually) after the relevant records are
loaded (catalogobject, LMI, and relations). Trying to do otherwise might
be inefficient and could unnecessarily constrain deployers in how they
load records.

LOCATION MOVEMENT

At the same time as you consider this proposal, we would like to call your
attention to a related use case, currrently unsupported, that may
complicate our choices.

see also:
http://wiki.collectionspace.org/pages/viewpage.action?pageId=95879255
http://wiki.collectionspace.org/display/deploy/Crates+and+other+mobile+containers
http://wiki.collectionspace.org/display/deploy/PAHMA+Storage+Location+data+mapping
some of which are pretty much "legacy documents" at this point)

We had attempted earlier to provided initial support for "movable
locations" -- a flag was added to the storage location schema to indicate
that the location was "movable", and this value was exposed as a check
box.  Movable locations ("crates", to use the PAHMA terminology) are
always located within another storage location, and the idea was to use
the BT/NT hierarchy to indicate the location of a crate.  This
implementation failed to work for PAHMA. The alternative was to make
"crates" a separate authority and to customize the LMI record to show both
a "standard" storage location and an optional crate.

You can see where this is going: if the implementation of "denormalized
locations" goes ahead as suggested above, would it be wise to consider the
handling of movable locations now as well?  If this feature is likely to
be needed in most cases (see wiki... for a discussion of use cases), then
doing the schema, UI, and services changes to support this at the same
time as locations are denormalized makes sense.  (The alternative, of
course, is to make movable containers a customization, as it is now).

Alas, I have to attach my standard dislaimer to this message:

"Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le
loisir de la faire plus courte!" -- Pascal

Regards,

John

read only authority refName in UI
show up in terms used?
able to pivot from UI?
is it enough to just go to the movement tab to see this?
(CRH: we've been encouraging people to stay on the cataloging tab)
mention crates

use an event handler?

batch process to update current location after IMPORT, to verify/update
locations after other maintenance.

Callable from an event handler

send quick note to Megan about reports...

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org