One of the problems we have with object packages is the apparently
finite number of object package names that can show in the drop down
when you do an advanced query for object package name.  The same seems
to hold true with fields like container name.  We have object packages
that alphabetically go up to "zuni", but when I search by object package
name in AQ, I can't search any higher than "Hevrdejs".

 

Is that being fixed in TMS 2010, or is it something that is able to be
fixed now with 9.35?

 

 

From: The Museum System (TMS) Users [mailto:[log in to unmask]]
On Behalf Of Jay Hoffman
Sent: Friday, July 30, 2010 1:52 PM
To: [log in to unmask]
Subject: Re: Object Package Names

 

That is already done and available in TMS 2010.

 

From: The Museum System (TMS) Users [mailto:[log in to unmask]]
On Behalf Of Felton, Larry
Sent: Friday, July 30, 2010 2:49 PM
To: [log in to unmask]
Subject: Re: Object Package Names

 

It would be really nice to some similar mechanism (e.g. folders) for
organizing reports as well.  

 

________________________________

From: The Museum System (TMS) Users [mailto:[log in to unmask]]
On Behalf Of Linda Pulliam
Sent: Friday, July 30, 2010 11:45 AM
To: [log in to unmask]
Subject: Re: Object Package Names

By department

Then by staff member

Then by project

 

Cheers

 

From: The Museum System (TMS) Users [mailto:[log in to unmask]]
On Behalf Of Jay Hoffman
Sent: Friday, July 30, 2010 2:41 PM
To: [log in to unmask]
Subject: Re: Object Package Names

 

I was thinking the same thing. It could be organized by owner, project
(a new field), global, etc.  How do you see the hierarchy groupings?

 

From: The Museum System (TMS) Users [mailto:[log in to unmask]]
On Behalf Of Ryan Donahue
Sent: Friday, July 30, 2010 11:27 AM
To: [log in to unmask]
Subject: Re: Object Package Names

 

We are actually looking at this problem now, folders would be a really
welcome addition to object packages (that is to say, a hierarchical
organization for object packages).

 

Our present plan is to expose a web interface for un/archiving object
packages on demand (we already have such an interface for transferring
object packages to our DAM).

 

My other thought was to treat global object packages like a communal
fridge -- periodically (2x year?) turning all global object packages
(with some exception) non-global, and letting people bug my department
when they need it (or use the web interface) to turn object packages
back on.

 

-Ryan Donahue

George Eastman House