<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1242986480;
mso-list-template-ids:155501202;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1
{mso-list-id:1866291493;
mso-list-type:hybrid;
mso-list-template-ids:-1813850732 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:2044985699;
mso-list-template-ids:-1167453858;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I think Kate’s approach sounds good. If the
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;background:white">processing_status_id / cataloged fields and their related dates that are currently showing as Events can simply be made to reappear (populated with the data they contain)
in the Collection Management subrecord (and Kate implies it’s actually already there in the tables), then we’re not necessarily proposing a sweeping deletion of folks’ data or a change to the data model—just a restoration of functionality that has been the
focus of this conversation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;background:white">Perhaps this could happen in a sequence of events like this:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><span style="mso-list:Ignore">1)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;background:white">Following a pull request and prioritization/acceptance, a future version of ASpace is released with processing and cataloged status options (pull-down
menus) and the other requisite fields that go along with them back in the Collection Management subrecord. Updating to this version doesn’t cause anyone to lose data—it just reappears as it was originally migrated.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><span style="mso-list:Ignore">2)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;background:white">The migration tool is re-configured, for those who aren’t in production yet, to have their AT processing status data mapped to the Collections Management
subrecord<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><span style="mso-list:Ignore">3)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;background:white">Institutions that want to wipe out their processing-related events can do so; if a plug-in is required to transfer data added to the Events module
(post-migration), that is developed as a final step<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;background:white">It’s easy to configure the events by adding and deleting fields to fit your needs. So I wouldn’t propose a reverse migration that wipes out processing events
for everyone—after all, while re-reading Brad’s post on this topic from November, this change was done with good intentions and was a deliberate extension of the PREMIS events model. I quote Brad here:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#2E75B6;mso-style-textfill-fill-color:#2E75B6;mso-style-textfill-fill-alpha:100.0%">“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.”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Some repositories may very well want to continue adding processing actions as events (i.e. “partially processed” by [agent] on [date]) to allow for granular reports on these
types of events and agents in the future. But it seems, <i>in addition</i>, institutions simply want an option via Collection Management to say: is this stuff processed, or not? Because an event is not necessarily the same as a status. As others have pointed
out, a status is just easier for querying and on-the-ground collection management.
<span style="background:white">A one-time version change that exposes those relevant fields that were moved to Events and plops them back into the Collection Management subrecord might be a suitable minimum “do no harm” approach. Plug-ins to migrate data between
the Events and Collections Management subrecords might be a slightly different issue.<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;background:white">Respectfully,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;background:white">Laurel<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Laurel McPhee Dougherty<o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Supervisory Archivist, Special Collections & Archives Program<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">UC San Diego Library |
</span><span style="font-size:10.0pt;font-family:Wingdings">(</span><span style="font-size:10.0pt;font-family:"Calibri",sans-serif">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">858-534-5619 |</span><span style="font-size:10.0pt;font-family:"Calibri",sans-serif">
</span><span style="font-size:10.0pt;font-family:Wingdings">*</span><span style="font-size:10.0pt;font-family:"Calibri",sans-serif">
</span><a href="mailto:l1dougherty@ucsd.edu"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#2E74B5">l1dougherty@ucsd.edu</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> archivesspace_users_group-bounces@lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces@lyralists.lyrasis.org]
<b>On Behalf Of </b>Bowers, Kate A.<br>
<b>Sent:</b> Wednesday, February 17, 2016 8:30 AM<br>
<b>To:</b> Archivesspace Users Group <archivesspace_users_group@lyralists.lyrasis.org><br>
<b>Subject:</b> Re: [Archivesspace_Users_Group] Collection management - processing status disappeared...<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I’m not sure that incorporating “reverse migration” for all into re-establishing the disappeared functionality would be wise. Rather a one-time “reversion helper”
plug-in, that can be optionally executed by an ArchivesSpace repository, is better.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Here’s my thinking</span><o:p></o:p></p>
<p style="background:white"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p style="background:white"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">1) Less work means more likelihood of getting the basic, vital functionality of “processing status” back into collection management records more quickly.
By this I mean: the table is still there with the data in it (at least for AT migrations). Just put it back into the interface and for users and admins.</span><o:p></o:p></p>
<p style="background:white"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">2) Status does not equal event. Status *<b>may</b>* be inferred from *<b>some</b>* events.
</span><o:p></o:p></p>
<p style="background:white"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">3) Individual implementers have control over their drop-down lists, thus, each type of event would have to be evaluated for its real-world meaning vis-a-vis
processing status. Automated monkeying might obfuscate the actual processing status. There is no way to know what can be automated across the board. Ergo, individual repositories have to govern these changes.</span><o:p></o:p></p>
<p style="background:white"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">4) Individual implementers may not need “reverse migration” and the labor might be in excess of the work needed to simply apply processing statuses to
accessions by hand. Questions to evaluate the need include: a) How much work would be involved in creating “reverse migration”? b) As far as I can tell, processing statuses that migrated from AT are still there. For many repositories, changing processing
status may not be that labor-intensive—it could be that not many accessions have been processed between migration and implementation. c) Did Archon have processing status? If so, were they also retained? d) How many repositories changed the default drop-downs
for event records?</span><o:p></o:p></p>
<p style="background:white"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p style="background:white"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Kate</span><o:p></o:p></p>
<p style="background:white"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Kate Bowers</span></b><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Collections Services Archivist for Metadata, Systems, and Standards</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Harvard University Archives</span><o:p></o:p></p>
<p class="MsoNormal"><a href="mailto:megan_sniffin-marinoff@harvard.edu"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">kate_bowers@harvard.edu</span></a><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">617.496.2713</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">voice: (617) 384-7787
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">fax: (617) 495-8011</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">web:
</span><a href="http://nrs.harvard.edu/urn-3:hul.eresource:archives"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">http://nrs.harvard.edu/urn-3:hul.eresource:archives</span></a><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Twitter: @k8_bowers</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">
</span><a href="mailto:archivesspace_users_group-bounces@lyralists.lyrasis.org"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">archivesspace_users_group-bounces@lyralists.lyrasis.org</span></a><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">
[</span><a href="mailto:archivesspace_users_group-bounces@lyralists.lyrasis.org"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">mailto:archivesspace_users_group-bounces@lyralists.lyrasis.org</span></a><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">]
<b>On Behalf Of </b>Runyon, Carolyn<br>
<b>Sent:</b> Tuesday, February 16, 2016 4:18 PM<br>
<b>To:</b> Archivesspace Users Group<br>
<b>Subject:</b> Re: [Archivesspace_Users_Group] Collection management - processing status disappeared...</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal">Chris, I’m going to answer two of the questions you posed in yesterday’s email according to UTC’s preference.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo5">
Yes, we would like to see processing event records migrated back to their original collection_management records and then removed.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo5">
Yes, we like to see processing tracked in collection_management only and have it removed as an option in events.<o:p></o:p></li></ul>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Carolyn<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="color:black">Carolyn Runyon<br>
Assistant Head of Collection Services and Director of Special Collections<br>
University of Tennessee at Chattanooga Library<br>
615 McCallie Ave., Chattanooga, TN 37403<br>
</span><a href="mailto:Carolyn-Runyon@utc.edu">Carolyn-Runyon@utc.edu</a><span style="color:black">, (423) 425-4503<br>
Dept. 6456, LIB 439D</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Feb 15, 2016, at 1:15 PM, Chris Fitzpatrick <<a href="mailto:Chris.Fitzpatrick@lyrasis.org">Chris.Fitzpatrick@lyrasis.org</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;background:white">One thing I am curious about is are people wanting to have this processing_status_id field added to the collection_management table, but are you wanting to have these event
records migrated back to collection_management records and then removed ( the migration to make this change moved the data from the collection_management table into events) ? Are you wanting to do away with the processing status in events completely?</span><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</body>
</html>