Re: [Archivesspace_Users_Group] Microfilm Numbers

[Rachel Donahue]

Hi Patsy,

I would probably put the microfilm number in as an External Document. The
Location doesn't *have* to be a URL, even if it's preferred.

--Rachel


On Mon, Apr 20, 2020 at 12:07 PM Hand, Sarit  wrote:

> HI,
>
>
>
> Are you creating Resource Records or Archival Object records for the
> microfilms? If so, can you use the MF# for the identifier there? You can
> spawn a record from the accession OR create a record then link the
> accession record.  Be aware that accession records can only be linked at
> the Resource Record level.  You can link as many as you want.
>
>
>
> Cheers,
>
> [image: cid:image001.jpg@01D16B1C.33577140]
>
>
>
> [image: signature-96]
>
>
>
>
>
>
>
> *Sarit Hand*
>
> Digital Archivist
> AP Corporate Archives
>
> *sh...@ap.org *
> www.ap.org
>
> 200 Liberty Street
>
> New York, NY 10281
>
> T 212.621.7035
>
> F 212.621.1723
>
>
>
>
>
> *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org <
> archivesspace_users_group-boun...@lyralists.lyrasis.org> *On Behalf Of 
> *Patricia
> Mitchell
> *Sent:* Monday, April 20, 2020 11:23 AM
> *To:* archivesspace_users_group@lyralists.lyrasis.org
> *Subject:* [Archivesspace_Users_Group] Microfilm Numbers
>
>
>
> Hi, I'm working on migrating legacy accession data to ArchivesSpace. All
> of our accessions have unique identifiers assigned to them, but some also
> have unique numbers assigned to them when they're microfilmed. An example
> would be: Ac. No. 2020-053, MF. 100. For migrating into ArchivesSpace, I
> would likely put 2020 in the first accession number field, followed by 053
> in the second accession number field, but what should I do with the MF
> number? This is info we'd like to retain obviously, and we could put it in
> a user-identified field, but I'm trying to avoid creating too many custom
> fields if there are appropriate fields already available in ArchivesSpace.
> Does anyone else have more than one unique identifier assigned to a
> collection? Any ideas for where to record this data?
>
>
>
> Patsy Mitchell
>
> Electronic Records Archivist
>
> Tennessee State Library & Archives
>
> Office of Tennessee Secretary of State Tre Hargett
>
> 403 7th Avenue North
>
> Nashville, TN  37243
>
> 615.253.8712
>
>
>
> This electronic mail may be subject to the Tennessee Public Records Act,
> Tenn. Code Ann. §10-7-503 *et seq*.  Any reply to this email may also be
> subject to this act.
>
>
>
> *The Mission of the Office of the Secretary of State is to exceed the
> expectations of our customers, the taxpayers, by operating at the highest
> levels of accuracy, cost-effectiveness, and accountability in a
> customer-centered environment.*
>
>
>
> Secretary of State Social Media Links:
>
> www.facebook.com/TennesseeSecretaryofState
> 
>
> www.facebook.com/TNStateLibraryArchives/timeline
> 
>
>
> The information contained in this communication is intended for the use of
> the designated recipients named above. If the reader of this communication
> is not the intended recipient, you are hereby notified that you have
> received this communication in error, and that any review, dissemination,
> distribution or copying of this communication is strictly prohibited. If
> you have received this communication in error, please notify The Associated
> Press immediately by telephone at +1-212-621-1500 and delete this email.
> Thank you.
> ___
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Seeking feedback on tickets by Feb. 1

[Rachel Donahue]

I'm having trouble logging in to comment (or even viewing issues, what's
up, Atlassian??), so I'll respond here.

*769: *Yes, please!

*773: *I agree with Ed Busch that both options (this and 950) should be
offered. 950 is about using CSS to print the current webpage rather than
the full finding aid PDF. I would, however, make it clear on the
button/with a text link that that is what's going to happen.

*357:* This sounds like a great feature to have, but also like it could
involve a fair amount of work. For us, it definitely isn't a high priority.

Best,
Rachel

On Tue, Dec 17, 2019 at 8:01 AM Tang, Lydia  wrote:

> Hello all!
>
>
>
> The Development Prioritization and Usability sub-teams have prepared a
> brief list of tickets that we are seeking community feedback on!
>
>
>
> Please feel free to comment on these tickets and/or discuss them on the
> list.  These tickets may be complex and/or have a high impact on the
> program, so we definitely would appreciate your thoughts on these!
>
>
>
>- Geolocation: https://archivesspace.atlassian.net/browse/ANW-357
>- Moving sidebar tree to the left:
>https://archivesspace.atlassian.net/browse/ANW-769
>- Downloading PDF from any view of the collection:
>
> https://archivesspace.atlassian.net/browse/ANW-773
> 
>
> Thank you for your feedback and consideration!  We’ll send a reminder
> after the new year, with the hope of finalizing feedback by the beginning
> of February.
>
> Lydia Tang and Maggie Hughes
>
> ~ on behalf of the Development Prioritization and Usability subteams
>
>
>
>
> ___
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Related accession and resource links on agent records

[Rachel Donahue]

Do you by any chance have multiple repositories? Agents will only show
related resources and accessions of the repository you currently have
selected.


--Rachel
--

Please note that I currently *do not have access to ARS email*. If you need
to contact me, use my LAC address: rachel.dona...@lac-group.com

The information contained in this e-mail message is confidential. If you
are not the intended recipient, any dissemination or copying is strictly
prohibited. If you think that you have received this e-mail message in
error, please contact the sender.


On Thu, Oct 17, 2019 at 10:29 AM Lucas, Dawne Howard 
wrote:

> Hi all,
>
>
>
> We recently migrated into ASpace from AT. I’ve been cleaning up agent
> records, and have noticed that some agent records don’t show which
> accession and resource records they are linked to. The resource and
> accession records indicate the link to the agent record, but not vice
> versa. Some of the agent records do display the links though, so I’m not
> sure why they appear on some records and not others.
>
>
>
> Have other people noticed this inconsistency, and is there an explanation
> for it?
>
>
>
> Thanks!
>
> -Dawne
>
>
>
> --
>
> Dawne Howard Lucas, MA, MSLS
>
> she/her/hers
>
> Technical Services Archivist
>
> Wilson Special Collections Library
>
> University of North Carolina at Chapel Hill
>
> 200 South Road, CB# 3926
>
> Chapel Hill, NC 27515
>
> T: 919-966-1776
>
> E: dawne_lu...@unc.edu
>
> Web: http://guides.lib.unc.edu/health-history
>
> ORCID:  orcid.org/ -0001-9657-8509
>
>
> ___
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Oddities when updating Agents via the API

[Rachel Donahue]

Alicia and Dave,

Thank you so much for your help! I was thrown by telephone having it's own
URI, but I guess I'll just have to accept the new creation dates. We're
using a hosted instance, so I unfortunately don't have MySQL access.

Dave-- the  JSON payload already contains the original created_by
information, so I don't think maually setting it by API is going to work.
Like I said, not make or break, just nice-to-have. The information for
subrecords doesn't even show in the staff interface, so I'm likely the only
one who would ever notice that it's happening.

Best,
Rachel

--

Please note that I currently *do not have access to ARS email*. If you need
to contact me, use my LAC address: rachel.dona...@lac-group.com

The information contained in this e-mail message is confidential. If you
are not the intended recipient, any dissemination or copying is strictly
prohibited. If you think that you have received this e-mail message in
error, please contact the sender.



>
> Message: 16
> Date: Fri, 11 Oct 2019 16:17:07 +
> From: "Detelich, Alicia" 
> To: Archivesspace Users Group
> 
> Subject: Re: [Archivesspace_Users_Group] Oddities when updating Agents
> via the API
> Message-ID: <5604120b-a726-4ed2-8537-0b94a6b49...@yale.edu>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Rachel,
>
> Basically, what you are seeing is that whenever a record is posted, all of
> its subrecords are deleted and recreated, even if no changes are made to
> the subrecords themselves. When this happens a new database identifier,
> create time, lock version etc. are assigned to each subrecord. I don?t
> think it?s a bug, per se, but it is an odd behavior that has come up
> numerous times in my work as well.
>
> I am not sure why the decision to design subrecords that way was made by
> the original developers of the application (if anyone has thoughts please
> let me know!), nor do I have a sense of the amount of work/consequences
> involved in updating the application so that subrecords are persistent.
>
> There isn?t a way to only post the changing fields via the API, since only
> top-level records (resources, archival objects, etc.) have their own URIs.
> An alternative solution would be to do a (very careful!) database update to
> the relevant field(s) in the relevant name table(s).
>
> Hope this helps,
>
> Alicia
>
> Alicia Detelich
> Archivist
> Manuscripts and Archives
> Yale University Libraries
>
> From:  on behalf
> of Rachel Donahue 
> Reply-To: Archivesspace Users Group <
> archivesspace_users_group@lyralists.lyrasis.org>
> Date: Friday, October 11, 2019 at 11:52 AM
> To: "archivesspace_users_group@lyralists.lyrasis.org" <
> archivesspace_users_group@lyralists.lyrasis.org>
> Subject: [Archivesspace_Users_Group] Oddities when updating Agents via the
> API
>
> Hi all,
>
> I'm running some bulk updates to Agents (in this case people) via the API
> and noticed some rather odd changes to sub-records when I check the JSON
> after successfully running the update.
>
> 1. Every sub-record (e.g. names, telephones) has replaced "created_by"
> with the user authenticated by the API and create_time with the time of the
> API call. The Agent itself retains its created_by and time, thankfully, but
> all the bits and pieces lose it.
> 2. Possibly related to this, a new telephone number is created even though
> nothing about the phone number has changed. (e.g. what was /telephone/99 is
> now /telephone/204)
> 3. The lock_version for the sub-records isn't changing from 0.
>
> The only thing changing in these updates is the name source and we're
> using ArchivesSpace 2.6.0. I have been reposting the entire object in the
> update--is it possible to post *only* the changing fields and perhaps avoid
> the problem?
>
> While this isn't a make-or-break problem, I'd really like to retain the
> created_by information for names, as it is often *not* the same as the
> person who created the initial record. I'm also not sure if this is a bug
> or something I'm doing wrong. Any insights would be much appreciated!
>
> Best,
> Rachel
>
>
> Message: 18
> Date: Sun, 13 Oct 2019 20:52:04 +
> From: "Mayo, Dave" 
> To: Archivesspace Users Group
> 
> Subject: Re: [Archivesspace_Users_Group] Oddities when updating Agents
> via the API
> Message-ID: <50e41cb5-5a5c-4359-b742-bdf5c9787...@harvard.edu>
> Content-Type: text/plain; charset="utf-8"
>
> There are a lot of sub-records in ASpace that are essentially treated as
> ephemeral but which have full concrete tables backing them; they?re not
> addressable in the system, their representations in the JSONModel

[Archivesspace_Users_Group] Oddities when updating Agents via the API

[Rachel Donahue]

Hi all,

I'm running some bulk updates to Agents (in this case people) via the API
and noticed some rather odd changes to sub-records when I check the JSON
after successfully running the update.

1. Every sub-record (e.g. names, telephones) has replaced "created_by" with
the user authenticated by the API and create_time with the time of the API
call. The Agent itself retains its created_by and time, thankfully, but all
the bits and pieces lose it.
2. Possibly related to this, a new telephone number is created even though
nothing about the phone number has changed. (e.g. what was /telephone/99 is
now /telephone/204)
3. The lock_version for the sub-records isn't changing from 0.

The only thing changing in these updates is the name source and we're using
ArchivesSpace 2.6.0. I have been reposting the entire object in the
update--is it possible to post *only* the changing fields and perhaps avoid
the problem?

While this isn't a make-or-break problem, I'd really like to retain the
created_by information for names, as it is often *not* the same as the
person who created the initial record. I'm also not sure if this is a bug
or something I'm doing wrong. Any insights would be much appreciated!

Best,
Rachel

--

Please note that I currently *do not have access to ARS email*. If you need
to contact me, use my LAC address: rachel.dona...@lac-group.com

The information contained in this e-mail message is confidential. If you
are not the intended recipient, any dissemination or copying is strictly
prohibited. If you think that you have received this e-mail message in
error, please contact the sender.
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group