Re: [Archivesspace_Users_Group] [EXT] Re: AS PUI displaying unpublished content

[Earle, Lev]

Hello everyone,

I wanted to send an update in case anyone else has been having this issue. The 
re-indexing did indeed work; it was also revealed during the review that there 
were a number of accession reports which had been published at some point, and 
these were still visible. This isn't part of our procedure, and we're uncertain 
exactly how it happened, but there are only a few hundred of them. We've turned 
off the PUI for now and are working on how to programmatically unpublish them, 
and make sure no accession reports are published through to the PUI.

Thanks again Andrew et al for your help!

Cheers,
-Lev.

___
Lev Earle
Special Collections Processing Archivist - RBSCP
University of Rochester River Campus Libraries
they/them pronouns

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Andrew 
Morrison
Sent: Tuesday, April 6, 2021 5:00 AM
To: archivesspace_users_group@lyralists.lyrasis.org
Subject: Re: [Archivesspace_Users_Group] [EXT] Re: AS PUI displaying 
unpublished content


Have you tried 
re-indexing
 since switching on the public user interface?



Andrew.




On 05/04/2021 23:54, Earle, Lev wrote:
Hi Mark,

Thanks for your response on this. Unfortunately, the publish/unpublish buttons 
in the staff interface aren't the source of the issue- the unpublished records 
do not have any "publish" boxes checked. I'd love it if it were that simple, 
haha. Additionally, we're running 2.5.1. We do have digital objects, but 
they're only linked to a few finding aids, all of which are published, so I 
don't think that should be causing the error, either... There doesn't seem to 
be any discrimination between what gets improperly displayed/published that 
would point to something linked causing the problem. Still, I'll review the 
workflow link you gave here with the tech folks and see if we can find 
something out.

Thanks again!

Cheers,
-Lev.

___
Lev Earle
Special Collections Processing Archivist - RBSCP
University of Rochester River Campus Libraries
they/them pronouns

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 

 On Behalf Of Custer, Mark
Sent: Monday, April 5, 2021 6:09 PM
To: 
archivesspace_users_group@lyralists.lyrasis.org
Subject: [EXT] Re: [Archivesspace_Users_Group] AS PUI displaying unpublished 
content

Lev,

Accession records can be published or unpublished in the staff interface, and 
if the accession records are unpublished, then those records should not show up 
in the ArchivesSpace PUI. If I recall correctly, though, there was a bug in the 
initial release of the PUI in ASpace 2.1 that showed unpublished Accession 
records as linked records when linked to other published records, so perhaps 
that was occurring in your version?  Also, it looks like there is still a bug 
for how linked records display if linked to a digital object record, as 
reported here: 
https://archivesspace.atlassian.net/browse/ANW-1207.

We only have accession records linked to resource (or other accession) records, 
and in that case, the unpublished accessions do not show up in the PUI. That 
said, I have noticed that if you add a LOT of linked accessions to any one 
record, then that can also cause an issue:  we have one miscellany collection 
that should have over 2,000 linked accession records, but we dropped that down 
considerably in the staff interface so that it wouldn't break the display for 
that resource record in the public interface. Ideally, we could link them all, 
but it's not a big hindrance since we record the call number for that resource 
record in all 2k accession records anyway -- so, the records can still be 
grouped that way for reporting.

Last, this page is woefully out of date, but I'll add the link here since it 
includes a few helpful pointers, specifically about the importance or reviewing 
the use of the Publish? button, default settings, and other workflows that 
impact publication statuses if using the PUI:  
https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/103526318/PUI+pre-launch+checklist

[Archivesspace_Users_Group] New blog post highlighting current ArchivesSpace Advisory Council Members

[Jessica Crouch]

[Sent on behalf of the ArchivesSpace User and Technical Advisory Councils]



Dear ArchivesSpace Members,



Leaders of the ArchivesSpace Technical and User Advisory Councils are pleased 
to announce the final blog in our series featuring various members of the 
councils. Throughout the month, we shared profiles of members from both 
councils. Through this series, we hope you’ve learned more about the work of 
the councils and will consider nominating yourself and/or colleagues for the 
councils.


Check out the last group of the series: https://archivesspace.org/archives/6888


Learn more about the councils: 
https://archivesspace.org/governance-board-and-councils


Interested in nominating yourself and/or a colleague for one of the councils? 
Use the form below. The deadline to submit is April 23.

To nominate yourself or someone else, visit: https://forms.gle/m2nN49M34CPgnvci9

Best,

Jessica Dowd Crouch
Community Engagement Coordinator for ArchivesSpace
jessica.cro...@lyrasis.org
[page1image482511520]

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

[Archivesspace_Users_Group] release candidate available - ArchivesSpace v3.0.0-RC2

[Christine Di Bella]

Hello ArchivesSpace members,

The ArchivesSpace team is pleased to announce a release candidate, v3.0.0-RC2. 
You can download it at 
https://github.com/archivesspace/archivesspace/releases/tag/v3.0.0-RC2 or test 
it out without downloading at http://test.archivesspace.org/staff  (username 
admin /password admin).

We have put out a second release candidate because a good deal of code has gone 
into our main branch since the release of the first release candidate. While 
some consists of improvements to the agents work that is the focus of v3.0.0, 
there have also been additional contributions from community developers and 
substantial work from the program team developers.

One of the community contributions I wanted to note is a new spreadsheet import 
feature from developers and archivists at Harvard University, focused on adding 
top containers and associated information to existing archival objects. With 
this feature, a user will download a file of archival objects for a resource, 
add top container information outside the application, and then import the 
information into the resource record, from the Load via Spreadsheet area. Some 
draft documentation for this feature written by Harvard Staff is available at 
https://docs.google.com/document/d/10poB5BDwgEWGYwrfLgkfy_sOjkhmbvStDat_BIm6ucw/edit?usp=sharing.
 Please feel free to leave feedback on the documentation.

Also included in the community contributions are a range of performance, 
backend and staff interface improvements courtesy of work Hudson Molonglo 
developers James Bullen, Mark Triggs, and Payten Giles did for Queensland State 
Archives as part of a larger project.

The core of this release candidate centers around changes to the agents module 
of ArchivesSpace to make it more standards-compliant with EAC-CPF and the 
MARCXML format for authority data, enabling deeper and richer description of 
people, families, and corporate entities, their relationships to each other and 
their relationships to materials held outside ArchivesSpace. This work is the 
result of a community specification written through the participation of many 
users across the ArchivesSpace community, mostly notably Cory Nimer, Sue 
Luftschein, and Brad Westbrook. Through this work new fields and sub-records 
have been added to the agents schema, and staff and public interface views, 
imports, exports, and auxiliary functionality like agent merging have all been 
updated. There is also a new Light mode for agents, which provides the option 
for users to continue to work with agent records in the staff interface in a 
pared down view that is similar to that of ArchivesSpace versions prior to this 
one.

Thanks to the many community members who made contributions as we worked on 
bringing this expanded functionality to ArchivesSpace, including both 
individual archives staff and developers and our Testing and User Documentation 
sub-teams.

Please try this release candidate out and let us know at 
archivesspaceh...@lyrasis.org by April 27 
if you notice any problems with the specific areas addressed in this release, 
or if anything that was working before no longer is. We are aiming to release 
3.0.0 by the end of the month.

Please get in touch if you have any questions. Thanks as always for your 
feedback and support.

Christine

Christine Di Bella
ArchivesSpace Program Manager
christine.dibe...@lyrasis.org
800.999.8558 x2905
678-235-2905


[ASpaceOrgHomeMedium]

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Should digital object file_uri field allow non URI data?

[Brian Hoffman]

Thanks for the feedback. I am inclined to think “A” as well, though 
implementing a validation at this point seems counterproductive since it make 
existing databases with markup / mixed content in there more problematic.

From:  on behalf of 
Andrew Morrison 
Reply-To: Archivesspace Users Group 

Date: Monday, April 19, 2021 at 1:26 PM
To: "archivesspace_users_group@lyralists.lyrasis.org" 

Subject: Re: [Archivesspace_Users_Group] Should digital object file_uri field 
allow non URI data?


Option A, because anything but a URI would create invalid EAD if exported or 
requested via OAI-PMH.

Andrew.


On 19/04/2021 17:41, Majewski, Steven Dennis (sdm7g) wrote:

I would think ‘A’, but that’s based on that the field is labeled “File URI” so 
I expect something that looks like a URI, and the fact that some notes in 
ArchivesSpace are explicitly labeled as allowing mixed content, and that has 
made me assume that allowing mixed content is not the default. But I guess that 
would not rule out ‘C’ as the original intention.

(Sometimes, if I assume something long enough, it turns into a rule in my head!)

I would also note that where mixed content is allowed, it doesn’t appear to be 
validated, and I’m seeing a lot of examples in the wild of invalid EAD exported 
with missing end tags, undeclared namespaces and other issues that prevent 
parsing EAD exported from ArchivesSpace. We probably should add a validation 
step where mixed content is allowed to attempt to parse the note as an XML 
fragment, and not accept the edit if it fails. ( I’ve been meaning to get 
around to testing this to see if there are any side effects or spurious 
rejections from doing this. )

— Steve.


On Apr 19, 2021, at 11:50 AM, Brian Hoffman 
mailto:brian.hoff...@lyrasis.org>> wrote:

Hi,

We have been trying to understand what to do about cases like the following:

http://sandbox.archivesspace.org/digital_objects/2/edit#tree::digital_object_2



As things are now, ArchivesSpace will allow a value like this, but various 
renderings and transformations will not work as expected. I am wondering if:


  1.  This is a legacy bug; the field should have originally validated values 
to ensure they were URIs
  2.  This is a presentation layer bug: non URIs should be allowed in the 
file_uri field, but HTML and PDF presentations need to accommodate that.
  3.  Everything is fine. Users should be able to put whatever they want in 
file_uri, but if they want it to present right they need to write a plugin.

This isn’t an academic question, as this is currently happening with records 
created automatically by Preservica software.

Brian
___
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
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group