[Archivesspace_Users_Group] Collection management - processing status disappeared...
Cyndi Shein
cyndi.shein at unlv.edu
Tue Feb 9 18:41:43 EST 2016
UNLV University Libraries supports AS-76 as well.
Cyndi Shein
Head, Special Collections Technical Services
University Libraries, University of Nevada, Las Vegas
cyndi.shein at unlv.edu (702) 895-2223
unlvspecialcollections <https://www.facebook.com/unlvspecialcollections>
On Tue, Feb 9, 2016 at 10:02 AM, Dougherty, Laurel <l1dougherty at ucsd.edu>
wrote:
> UC San Diego concurs. The experience (and resulting complications with
> managing data effectively) that Anne describes below are identical to UC
> San Diego’s, and we too support AS-76.
>
>
>
> *Laurel McPhee Dougherty*
>
> Supervisory Archivist, Special Collections & Archives Program
>
> UC San Diego Library | ( 858-534-5619 | * l1dougherty at ucsd.edu
>
>
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Engelhart,
> Anne
> *Sent:* Tuesday, February 09, 2016 8:58 AM
> *To:* Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
> *Cc:* Sniffin-Marinoff, Megan <megan_sniffin-marinoff at harvard.edu>
> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
> processing status disappeared...
>
>
>
> I’ve been asked by the Harvard ArchivesSpace Interim Steering Group to
> post Harvard University’s position on AS-76. I also posted it on JIRA,
> AS-76. (Here it is below.)
>
>
>
> Anne Engelhart
>
> Head, Collection Services
>
> Schlesinger Library, Radcliffe Institute
>
> 10 Garden St.
>
> Cambridge, MA 02138
>
> 617.495.8521
>
>
>
> *Restoration of processing status to collection management records in
> ArchivesSpace*
>
> *Summary *
>
> Sometime during the past year, ArchivesSpace made a major change to its
> functionality.
>
> · It eliminated the processing status from collection management
> records.
>
> · The processing status and associated date were converted to
> “event” records.
>
> This has created several problems for archivists at Harvard who rely on
> this information for workflow and reporting purposes including:
>
> · The “processing status” in all accessions migrated from the
> Archivists’ Toolkit (AT) for which processing statuses were assigned now
> displays as “Not specified” (see Screenshot 1).
>
> · The conversion of processing status from a condition (or type)
> to an event overcomplicates what was previously a fairly straightforward
> piece of collection management information.
>
> *Detailed discussion of issues*
>
> There are three troubling issues associated with this change in
> functionality.
>
> 1. The first should be important to all archives: by converting the
> processing status to an event, the ArchivesSpace developers have changed
> the nature of the data. A status is not equivalent to an event, although
> they can be related. There is one and only one “status” at any one time,
> but there can be multiple events. Events can lead to status changes. For
> example, two “partially processed” events may or may not lead to a status
> of “processed,” because it is entirely possible that three or more
> processing events might be needed to conclude that the status of the
> collection is “processed.” In addition, some statuses may have no relation
> to an event. For example “Unknown” is a possible processing status.
> Finally, how does an archivist identify “unprocessed” accessions in this
> scenario? This is another “non-event”. Are ArchivesSpace users expected to
> run a report on all accessions and look for those for which there is no
> “processing” event? Since there are many possible event types, this seems
> counter-productive and unnecessarily complex.
>
>
>
> 2. The second issue is perhaps unique to Harvard albeit no less
> critical. The Harvard AT-to-AS migration did not create event records based
> on processing status. Instead, while our back-end data has processing
> status in it, these statuses are, troublingly, not visible to staff.
> Instead the processing status displays as “not specified” (Screenshot 1).
> The same record in AT displays a processing status. (Screenshot 2)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Screenshot 1*
>
> *Screenshot 2*
>
>
>
> 3. Processing status is a critical piece of information that should
> be available to archivists for reporting on their accessions. In Harvard's
> current ArchivesSpace environment is that it is not possible to understand
> the scope and nature of our backlogs. The staff member who discovered this
> issue previously used the AT to readily determine the number of unprocessed
> accessions. While attempting to gather the same information from
> ArchivesSpace, the staff member found that it was not possible to achieve
> the same results with existing ArchivesSpace functionality.
>
>
>
> It is essential to the Harvard University ArchivesSpace user community
> that processing status be restored to its original functionality. The
> restoration of processing status to collection management records would:
>
> · Allow archivists to report out on backlog and processing
> statistics;
>
> · Assist archivists in resource allocation planning for grant
> proposals and yearly projects; and
>
> · Make this data currently in the back-end of ArchivesSpace
> easily available to archivists
>
> As such, Harvard University ArchivesSpace user community supports the JIRA
> ticket (AS-76) submitted by Matt Francis of Penn State Libraries.
>
>
>
>
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [
> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org
> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *MATTHEW
> R FRANCIS
> *Sent:* Monday, January 04, 2016 12:56 PM
> *To:* Archivesspace Users Group
> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
> processing status disappeared...
>
>
>
> Quick FYI update for anyone interested in this thread. After a couple of
> off-list discussions I decided to go ahead an create a new "feature
> request" ticket in JIRA requesting that the "Processing Status" field be
> restored to the Collection Management sub-record. The ticket can be viewed
> at: https://archivesspace.atlassian.net/browse/AS-76 (my apologies for
> forgetting to submit in the form of a user story!).
>
>
>
> If there are any questions, concerns, or clarifications that I can help
> with related to the request please let me know.
>
>
>
> -Matt
>
>
>
> *Matt** Francis*
>
> Archivist for Collection Management
>
> Special Collections Library
> Penn State University
>
>
> ------------------------------
>
> *From: *"MATTHEW R FRANCIS" <mrf22 at psu.edu>
> *To: *"Archivesspace Users Group" <
> archivesspace_users_group at lyralists.lyrasis.org>
> *Sent: *Wednesday, November 25, 2015 4:50:24 PM
> *Subject: *Re:
> [Archivesspace_Users_Group] Collection management - processing status
> disappeared...
>
>
>
> Thank you Brad for your explanation for why the change occurred with the
> processing status field, and thank you Kate, Noah, and Carolyn for your
> additional thoughts and feedback.
>
>
>
> Based on all of the provided feedback I asked some of our staff to
> work/test the new functionality while trying to consider the intent behind
> the changes, our existing local workflows and collections metadata, and the
> abstract "what do we consider processing status to mean". Based on this
> examination of the new functionality we would like to provide the following
> feedback (many of which have already been stated in this email thread):
>
> - In regards to "an event record allows much more information to be
> associated with the event", it has been our local practice and belief that
> more nuanced processing information that would help researchers and staff
> better understand a finding aid/the physical collection should be recorded
> in a corresponding "Processing Information" note (which is informed by our
> interpretation of DACS 7.1.8). That said, we do appreciate that the event
> record allows for the capturing of some metadata that would be less
> relevant to researchers, and consequently a place where additional metadata
> could be recorded outside of the aforementioned note field.
> - After examining our "processing status" data and discussing the new
> functionality, we agree with Kate's observation that "events and processing
> statuses are not logical equivalents." Additionally, we also agree with
> Noah's comment "that a resource or accession will always have only one
> current status."
> - Additionally, based on our examination, we do not believe that is
> ideal or logical to separate "processing status" from collection management
> records that still include: "processing priority", "processing plan", and
> "processors".
> - Our local workflows appear to be at a high level similar to what
> Carolyn has reported, and along with the data we had already created to
> take advantage of the previous functionality, we also preferred the
> simplicity of the processing status being a simple drop-down selection in
> the collection management records.
> - Based on our local use the processing status field, along with the
> current status of the ASpace tool, we found it much easier to report on
> collection status and to locate appropriate collections projects for our
> workers with the previous functionality over the current.
> - Finally, we also echo Kate's sentiment in that we do not understand
> why the new event features requires the removal of the processing status
> from the collection management records and consequently wonder if there is
> any reason not to have both?
>
> Due to the above points we are of the opinion that if the new event
> features cannot be appropriately maintained while also having the
> processing status functionality reside in the collection management
> records, we would be in favor of a return to the previous functionality, or
> a new approach that is more similar to the previous functionality. With
> that said, we understand that our rationale for this request is largely
> based on our local understanding of the role of the processing status
> field, our local workflows, and and our existing data. Because of this we
> recognize that not all ASpace members might share our perspective, and
> consequently we welcome continued discussion on this subject as appropriate.
>
>
>
> Thank you again to everyone who have already participated in the
> conversation, and we hope that as a community we can reach a consensus on
> the best direction for us to proceed in the near future.
>
>
>
> Hope all of you have a wonderful Thanksgiving.
>
>
>
> -Matt
>
>
>
> *Matt** Francis*
>
> Archivist for Collection Management
>
> Special Collections Library
> Penn State University
>
>
> ------------------------------
>
> *From: *"Runyon, Carolyn" <Carolyn-Runyon at utc.edu>
> *To: *"Archivesspace Users Group" <
> archivesspace_users_group at lyralists.lyrasis.org>
> *Sent: *Tuesday, November 24, 2015 2:12:09 PM
> *Subject: *Re:
> [Archivesspace_Users_Group] Collection management - processing status
> disappeared...
>
>
>
> We used the Processing Status field in the Collection Management module to
> track processing of our all our Resource records. It’s a little less
> complex than the data needed to populate an Event. I preferred the basic
> dropdown menu offered in Collection Management because it doesn’t require
> and Event Date/Time or a link it to an Agent. With legacy data, I won’t
> able to link an accurate Agent or Date to my processing events, which means
> I’ll have to devise some sort of input workaround for undated and anonymous
> Events.
>
>
>
> One last note, when Processing Status became and Event, Event Date/Time
> and Agent Links were populated, but they’re not accurate. They appear to
> reflect the Agent who selected the Processing Status and the Timestamp of
> when the Agent made the Processing Status selection. This means that if I
> want accurate data, I’ll need to clean up this legacy data.
>
>
>
> Cheers,
>
> Carolyn
>
>
>
>
>
>
>
> Carolyn Runyon
> Assistant Head of Collection Services and Director of Special Collections
> University of Tennessee at Chattanooga Library
> 615 McCallie Ave., Chattanooga, TN 37403
> Carolyn-Runyon at utc.edu, (423) 425-4503
> Dept. 6456, LIB 439D
>
>
>
> On Nov 19, 2015, at 9:57 AM, Noah Huffman <noah.huffman at duke.edu> wrote:
>
> I tend to agree with Kate here. It seems useful to allow a resource or
> accession to have lots of processing events associated with it (who did
> what, when), but it also seems that a resource or accession will always
> have only one current status (processed, not processed, partially
> processed, etc.).
>
>
>
> Also, associated events do not display in “edit” mode for resources or
> accessions (collection management sub-records do). As a result, it’s a bit
> complicated to figure out what the processing status is if you have to sort
> through a long list of associated events in “view” mode.
>
>
>
> -Noah
>
>
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [
> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org
> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *Bowers,
> Kate A.
> *Sent:* Thursday, November 19, 2015 9:40 AM
> *To:* Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
> processing status disappeared...
>
>
>
>
> Brad,
>
> Thanks for your very thorough reply!
>
> I think you presented this as an either/or choice. However, because
> events and processing status are not logical equivalents (they may be
> associated in that the status may be the result of an event, but it does
> not have to be), I do not understand why adding features to the events
> record requires removal of the status. I short, is there any reason not to
> have both?
>
> Thanks again,
>
> Kate
>
> Kate Bowers
> Collections Services Archivist for Metadata, Systems, and Standards
> Harvard University Archives
> Cambridge, Massachusetts, USA
> voice: (617) 384-7787
> fax: (617) 495-8011
> kate_bowers at harvard.edu
> ------------------------------
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of
> Brad Westbrook <brad.westbrook at lyrasis.org>
> *Sent:* Wednesday, November 18, 2015 6:04:27 PM
> *To:* Archivesspace Users Group
> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
> processing status disappeared...
>
>
>
> Hi.
>
>
>
> Certainly it is possible and reasonable to have a discussion of how to
> adjust this change in functionality to make it more satisfying and less
> confusing, including reverting back to the functionality first included in
> ArchivesSpace.
>
>
>
> As I recall that functionality, it consisted of the ability to link a
> single collection management record to a material description record
> (accession, resource, or digital object but not components for resources
> and digital objects) and, further, to indicate in that collection
> management record the processing status of the material being described.
> Default terms were “completed”, “in_progress”, and “new”, but the
> controlled value list was completely configurable. So institutions could
> add any terms they wanted to that list but they could only ever apply one
> status term to the material being described at a given time.
>
>
>
> We removed this field from the collection management field with the
> understanding such data would be better handled as event information and
> with the understanding that a change in status is first an event
> accomplished at a time and by an agent. We envisioned several benefits to
> this change:
>
>
>
> 1) As before, an organization has complete liberty to decide what
> terms it wants to use for expressing processing events and changes in
> processing status, as well as for any other events an institution chooses
> to track. The “Event Event Type” list is completely configurable.
>
>
>
> 2) An event record allows much more information to be associated
> with the event, including a descriptive note about the event, when the
> event occurred, and who was responsible for the event. It struck us that
> knowing that processing of a collection was completed on a certain date and
> by a certain individual could be more useful information that know
> processing was simply completed.
>
>
>
> 3) Multiple event records can be associated to the same material
> description record. For instance, using event records it would be possible
> to indicate when processing of material started in one event record and
> when it was completed in another.
>
>
>
> 4) Multiple event records can be linked to component records. Thus
> for processing projects split into parallel parts, it would be possible to
> track, say, the processing progress of series.
>
>
>
> In short, our belief is that the collection management record in
> conjunction with event records provides a more comprehensive and flexible
> way for organizations to record collection management information. In that
> relationship, the collection management record is the location for
> planning—indicating processing priority, estimating processing time,
> indicating processing plan(s) and processor(s), but also noting funding
> source and whether rights are determined (it’s questionable whether or not
> these last two should be included in the collection management
> record)—while the event record is for recording completion (or not) of
> processing / administrative tasks associated with the materials—acquiring a
> purchase agreement, starting processing, completing processing, etc.
>
>
>
> There are requisites for this, of course:
>
>
>
> 1) Institutional policies regarding what events are to be tracked
> and what event vocabulary is to be used.
>
>
>
> 2) A process for creating and sharing reports that relate material
> descriptions, collection management, and events in meaningful ways. A
> segment of the ArchivesSpace community has been working to develop a
> reporting process, but the trajectory being taken will place the burden on
> institutions to define reports (You can, btw, see a record of this effort at
> https://archivesspace.atlassian.net/wiki/display/AC/2015-16+Reports
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_2015-2D16-26-2343-3BReports&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=8UVzAZgZUYCTKzwFwtZ-ItCHeuR_vGn6ZXiJbokIYsc&e=>
> (current work) and
> https://archivesspace.atlassian.net/wiki/display/AC/Reports+Sub-team
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_Reports-26-2343-3BSub-2Dteam&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=gR2KAeUPGvIhxYIWoXd34WpOx_Fv8C2o6k7-biJ_1S0&e=>
> (past work). It was also noted in the ArchivesSpace developers meeting
> last week, that information of this type would be very suitable for
> displaying in a dashboard widget. Of course, institutions can already
> build their own reporting and define their own reports by using report
> software to extract and format data from the ArchivesSpace MySQL database.
>
>
>
> But these would be requisites for any collection management information,
> supplemented or not by event information. They would be requisites for a
> reversion for a return to the previous data model.
>
>
>
> Let me close with two observations to other parts of this thread:
>
>
>
> 1) The display problem that Noah noted in his comment yesterday is a
> remnant of moving collection status to events. There is a bug report
> requesting its correction at AR-1324
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1324&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=_4rsWhuS5vR89lgPot1DeY3XwBuDLb5wp_nbHwCIMZI&e=>
> .
>
>
>
> 2) The presence of the “Collection Management Processing Status” in
> the list of controlled values is also remnant of that change. It should be
> removed , unless there is a collective decision to revert. Thanks for
> pointing that out, Kelly.
>
>
>
> So it would be great to hear others weigh in on this. Collection
> management and event information have, as far as I know, no prevailing
> models or standards that we can simply follow. The closest to such is the
> de facto collection management sub-record created for accessions in the
> Archivists’ Toolkit, which was generalized for all top-level material
> descriptions in ArchivesSpace and supplemented by the inclusion of events.
> The ArchivesSpace event module is itself an extension of the PREMIS events.
>
>
>
> Best,
>
>
>
> Brad W.
>
>
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [
> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org
> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *MATTHEW
> R FRANCIS
> *Sent:* Wednesday, November 18, 2015 4:49 PM
> *To:* Archivesspace Users Group
> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
> processing status disappeared...
>
>
>
> For the reasons outlined by Kate, and seconded by Glynn, we have also
> found this change rather confusing, and unfortunately it has hampered our
> ability to identify and report on various issues related to processing
> status, including the previously mentioned backlog issue.
>
>
>
> I do not know if this is an issue that others would like revisited, but
> from our perspective we would welcome a conversation on if there is better
> alternative moving forward (including possibly reverting back to the
> pre-v1.3 set-up).
>
>
>
> -Matt
>
>
>
> *Matt* *Francis*
>
> Archivist for Collection Management
>
> Special Collections Library
> Penn State University
>
>
> ------------------------------
>
> *From: *"Glynn Edwards" <gedwards at stanford.edu>
> *To: *"Archivesspace Users Group" <
> archivesspace_users_group at lyralists.lyrasis.org>
> *Sent: *Wednesday, November 18, 2015 11:13:44 AM
> *Subject: *Re: [Archivesspace_Users_Group]
> Collection management - processing status
> disappeared...
>
>
>
> Hi Kate,
>
> We're on the same page...I too find this rather confusing. It is not
> straightforward enough for tracking status of collections across holdings
> easily.
>
> Cheers,
>
> Glynn
>
>
>
> Glynn Edwards
> Head, Technical Services
> Director, ePADD project
> Special Collections
> Stanford University Libraries
> Stanford, CA 94305-6064
> (650) 521-2255 | gedwards at stanford.edu
>
>
> ------------------------------
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of
> Bowers, Kate A. <kate_bowers at harvard.edu>
> *Sent:* Tuesday, November 17, 2015 1:08 PM
> *To:* Archivesspace Users Group
> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
> processing status disappeared...
>
>
>
> I am very confused. Can you explain how this is would work? How is an
> archivist supposed to understand an accession’s status from one or more
> associated “events” rather than from a straightforward status? I can also
> see how this would make reporting out backlogs really difficult.
>
>
>
> The reason I ask is that I can see how an event can lead to a status, but
> it is entirely possible that a status may have no associated event.
> Furthermore, the same type of event may lead to different statuses.
>
>
>
> In brief, status is not the same as “event”. I can think of a couple of
> examples to illustrate this:
>
> · “Unknown” can be a status, but it has no associated event
>
> · “Partially processed” can be both a status an event. However,
> if one “partially processes” an accession once, then the accession remains
> partially processed. If one “partially processes” again, it could be that
> the processing has been completed and the accession’s status is now
> “processed” or it could be that the accession is still only “partially
> processed” and that additional processing events will be necessary to reach
> a “processed” status.
>
>
>
> Thanks,
>
>
>
> Kate
>
>
>
>
>
> *Kate Bowers*
>
> Collections Services Archivist for Metadata, Systems, and Standards
>
> Harvard University Archives
>
> kate_bowers at harvard.edu <megan_sniffin-marinoff at harvard.edu>
>
> 617.496.2713
>
> voice: (617) 384-7787
>
> fax: (617) 495-8011
>
> web: http://nrs.harvard.edu/urn-3:hul.eresource:archives
>
> Twitter: @k8_bowers
>
>
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [
> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org
> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *Noah
> Huffman
> *Sent:* Tuesday, November 17, 2015 3:01 PM
> *To:* Archivesspace Users Group
> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
> processing status disappeared...
>
>
>
> Hi Kelly,
>
>
>
> During a previous release (v1.3), I think Processing Status was moved from
> the collection management subrecord to an Event record. Here is a JIRA
> issue describing this change:
> https://archivesspace.atlassian.net/browse/AR-827
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D827&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=AZTgid9lXUTh7glUns7pyqqX7w28sAhx7rK3QIIMb8o&e=>
>
>
>
> Here are some specifics:
>
> Remove “Processing Status” Collection Management sub-record
>
> If data is present, migrate to Event record with these settings and linked
> to same record collection management sub-record is linked to:
>
>
>
> Type = “Processing [Value in Collection Management Record for Processing
> Status]”
>
>
>
> Date/Time Specifier = “Time stamp for last modification of Collection
> Management record”
>
>
>
> Label= Agent relationship
>
>
>
> Type=Single
>
>
>
> Role=Implementer
>
>
>
> Agent=ID of agent last modifying the collection management sub-record
>
>
>
>
>
> So, if you previously had processing status in a collection management
> subrecord, you might try browsing your event records to see if you can
> locate that data.
>
>
>
> Hope this helps,
>
>
>
> -Noah
>
>
>
> ================
>
> Noah Huffman
>
> Archivist for Metadata, Systems, and Digital Records
>
> David M. Rubenstein Rare Book & Manuscript Library
>
> Duke University | 919-660-5982
>
> http://library.duke.edu/rubenstein/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__library.duke.edu_rubenstein_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=_GXkqn82Z-IInAOMJ80LH9QqQ2QNs6vZ496YUW6DDdw&e=>
>
>
>
>
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [
> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org
> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *Kelly
> Spring
> *Sent:* Tuesday, November 17, 2015 2:40 PM
> *To:* archivesspace_users_group at lyralists.lyrasis.org
> *Subject:* [Archivesspace_Users_Group] Collection management - processing
> status disappeared...
>
>
>
> Hello!
>
>
>
> Our Processing Status field is visible when using the Manage Controlled
> Value Lists feature; but is not present when actually working within a
> collection management sub-record in an accession or resource. Any tips or
> advice out there?
>
>
>
> Thank you and have a great day!
>
> *Kelly
>
>
>
>
>
>
>
>
>
> Kelly Spring
>
> Archivist for Special Collections
>
> University of California, Irvine Libraries
>
> (949) 824-6573
>
> http://special.lib.uci.edu
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=zFl3APrxF-DYAdjHiyHfabcKKA8Exkt6l-SzojCi4hA&e=>
>
>
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=>
>
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=QRZODf9XXD3bgxGHWgBXsAvw7uhg6gGfVUJ1KmSajT8&m=0Ck_7IMJVnx6wohz4qKGlbGyhudg134OSblcthSYEpo&s=Hy6Jm25S5RX5J4co3hzouZaE-u_g-orFLrA1i0aglwU&e=>
>
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/dcdcf2ec/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 11771 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/dcdcf2ec/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 38864 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/dcdcf2ec/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 49510 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/dcdcf2ec/attachment-0001.png>
More information about the Archivesspace_Users_Group
mailing list