Re: [Archivesspace_Users_Group] File naming errors in PUI

[Blake Carver]

Might just be missing from the locales:
https://github.com/archivesspace/archivesspace/blob/master/public/config/locales/en.yml#L178-L179

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Nic 
Stanton-Roark 
Sent: Thursday, September 30, 2021 1:58 PM
To: Archivesspace Users Group 
Subject: [Archivesspace_Users_Group] File naming errors in PUI

Hi all,

This week we upgraded from 2.7.1 to 3.1.0. Soft reindexing took care of most 
apparent issues, but one thing that newly appears is that files with dates but 
no utilized name field display with the description "translation missing: 
en.inherited" as so:

[image.png]

Is this either a known issue or is there a way to detect the issue in our logs? 
Thanks for any guidance you can provide

Best wishes,
Nic


[https://anderson.edu/uploads/au-email-logo.gif]
Nicholas Stanton-Roark  |  Archivist  | Robert A. Nicholson University Library
Anderson University  |  1100 E. Fifth St, Anderson, IN 46012
(765) 641-4285  |  
ndro...@anderson.edu
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

[Archivesspace_Users_Group] Calculate Dates not working

[Yatsonsky, Nicole]

Hi y'all,

Has anyone gotten this error: "Date is invalid and could not be created" when 
trying to create a date record using the Calculate Dates feature?

Screenshot here:

[Graphical user interface, application  Description automatically generated]

The dates are normal and there are no wonky characters, so I can't figure out 
why it's not working. It happens with every resource I've tried and at every 
archival object level. I tried without typing in the Expression field, and that 
didn't matter either. I can just manually add them instead, but I want to make 
sure this is addressed if it's fixable, since it's not working anywhere.

Just wondering if anyone had come across this before and could provide some 
info before I ran it by our IT people.

Thanks!

Nicole Yatsonsky, CA
Special Collections Library Specialist
Randall Library
UNC Wilmington
910.962.3412

"The great use of a life is to spend it for
something that outlasts it."  ~ William James

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

[Archivesspace_Users_Group] File naming errors in PUI

[Nic Stanton-Roark]

Hi all,

This week we upgraded from 2.7.1 to 3.1.0. Soft reindexing took care of
most apparent issues, but one thing that newly appears is that files with
dates but no utilized name field display with the description "translation
missing: en.inherited" as so:

[image: image.png]

Is this either a known issue or is there a way to detect the issue in our
logs? Thanks for any guidance you can provide

Best wishes,
Nic



*Nicholas Stanton-Roark*  |  Archivist  | Robert A. Nicholson University
Library
Anderson University  |  1100 E. Fifth St, Anderson, IN 46012
(765) 641-4285 <%28765%29%20641%204285>  |  ndro...@anderson.edu
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

[Archivesspace_Users_Group] ArchivesSpace Update - September 2021

[Jessica Crouch]

  [cid:image001.jpg@01D7B5DB.0A8C6F80]


ArchivesSpace Update – September 2021



Development


ArchivesSpace v3.1 is currently available. ArchivesSpace is announcing the 
availability of v3.1.0. You can download it at 
https://github.com/archivesspace/archivesspace/releases/.



This release includes a number of accessibility improvements, particularly to 
the public interface. Many of these were identified in an accessibility audit 
conducted by Deque across the open source applications that make their homes at 
LYRASIS, which include DSpace, CollectionSpace, and ArchivesSpace. The release 
also includes specific bug fixes and small feature improvements prioritized by 
the Development Prioritization sub-team. There are also additional performance, 
backend and staff interface improvements from Hudson Molonglo developers James 
Bullen, Mark Triggs, and Payten Giles that derived from work HM did for 
Queensland State Archives as part of a larger project.


Thanks to all of our community members who contributed code for this release: 
Alex Duryee, Andrew Morrison, Dave Mayo, James Bullen, Mark Triggs, Nick 
Butler, Payten Giles, Sam Hatfield, and Sean Anderson. As always, program team 
members Lora Woodford, Brian Hoffman, and Mark Cooper, as well as contractors 
Manny Rodriguez and Brian Zelip, wrote and/or reviewed substantial code for the 
release. Thanks also to our community groups, especially the Testing sub-team, 
for their efforts.



Information on upgrading to a new version of ArchivesSpace is available at 
https://archivesspace.github.io/tech-docs/administration/upgrading.html. If you 
have any difficulties, please let us know.



This is the spring/summer 2021 release from the 
roadmap.
 Items that were projected for this release that did not make it in have been 
shifted to future releases.



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



Upcoming Change to the Way ArchivesSpace is Deployed


We wanted to alert you to an upcoming change in the way the ArchivesSpace 
application is deployed. This change will not be noticeable to end users of the 
application, but it will affect those that install and maintain it for users.



Background



ArchivesSpace uses Solr for its search platform. 
Since its original release in 2013, ArchivesSpace has used a version of Solr 
that can be embedded into the application so that Solr is installed and 
configured by default when ArchivesSpace is installed. Though most 
ArchivesSpace deployments opt for this embedded version of Solr, some sites 
choose to use an external deployment of Solr and maintain it separately from 
ArchivesSpace.



In its own upgrades over the years, Solr made some changes so that it can no 
longer be embedded. While we have stayed on the highest embeddable version of 
Solr (v4.10.4) for years, this version is now old and unsupported by its 
maintainers, and it is no longer sustainable for us to use it in new releases. 
In order to maintain and improve this critical piece of ArchivesSpace 
infrastructure, we need to upgrade Solr. In the process we will need to make 
the transition to using external Solr only.



What does this mean for me?



Once we make this change, if you are responsible for deploying ArchivesSpace at 
your institution, you will need to download and install Solr and use 
ArchivesSpace’s supplied Solr configuration to create the Solr index. This will 
be in addition to managing your own MySQL database. Solr will no longer be 
distributed with ArchivesSpace and ArchivesSpace will no longer work 
out-of-the-box without an external Solr deployment. ArchivesSpace will need to 
be fully re-indexed when this transition occurs.

If you are not the person responsible for deploying ArchivesSpace at your 
institution, this change will not directly affect you, though it will be 
important to make sure the person responsible for deploying your ArchivesSpace 
is aware of the change.

Will you have strict requirements for how to deploy Solr?

Like with MySQL, the ArchivesSpace team does not intend to be opinionated about 
how Solr is deployed externally. System administrators will be able to use 
whatever method they prefer to install Solr. For those who require more 
guidance, however, we will have instructions for using a standalone Solr 
installation along with specific ArchivesSpace Solr configuration files. These 
will be in addition to the standard documentation provided by Solr 
(https://solr.apache.org/guide/8_9/installing-solr.html).

When will this happen?

We expect to make the transition to external Solr with the release on the 
roadmap
 that is planned for December 2021. Even so, older versions of ArchivesSpace 
will continue to work with the 

Re: [Archivesspace_Users_Group] [EXTERNAL] Re: Apache/httpd interfering with ASpace functionality

[Huebschen, Alan M]

Update to issue:


The problem was with a SSL/TLS setting that is not recommended by the ASpace 
docs, but one put in place to appease a security scanner:


Header set Content-Security-Policy "object-src 'self'; script-src 'self' 
'unsafe-inline'"


When set, this appears to disable some functionality within the staff interface.


-Alan



From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of 
Huebschen, Alan M 
Sent: Thursday, September 30, 2021 8:20 AM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] [EXTERNAL] Re: Apache/httpd 
interfering with ASpace functionality


Hi Blake,


I have checked the apache logs, browser dev console, and archivesspace.out for 
some sort of related error messages but there is nothing. Nothing has appeared 
in the httpd log since hours before I started testing this morning. Nothing 
appears in the browser dev console when I attempt to click the 'Delete' button. 
I'm rather unsure how to troubleshoot this other than temporarily disabling 
SSL/TLS through apache and readding my config changes slowly.


-Alan



From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Blake 
Carver 
Sent: Wednesday, September 29, 2021 12:33 PM
To: Archivesspace Users Group
Subject: [EXTERNAL] Re: [Archivesspace_Users_Group] Apache/httpd interfering 
with ASpace functionality

Check your Apache logs for errors. Sounds like maybe it's some kind of issue 
there.
Also, check the browser devtools counsel for errors, they are likely to show up 
there too.
Also check the archivesspace.out log for errors, might be something in there.

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of 
Huebschen, Alan M 
Sent: Wednesday, September 29, 2021 1:06 PM
To: Archivesspace Users Group 
Subject: [Archivesspace_Users_Group] Apache/httpd interfering with ASpace 
functionality


Good morning,


I have recently been made aware of some issues with functionality in our 
ArchivesSpace instance. Users are unable to perform some tasks, such as use the 
"Delete" button to delete records. I have tested my dev and prod copies of 
ASpace against local and remote DBs. My dev instance works perfectly fine, it 
does not use Apache/httpd for SSL/TLS but our production instance does. When I 
bypass Apache/httpd on the production instance, all of the functionality issues 
vanish.


We are currently running ArchivesSpace v3.1.0 and just upgraded from v2.8.0. 
The issues began in v2.8.0 and remain after our upgrade to v3.1.0.


Has anyone else run into similar issues with Apache/httpd or Nginx interfering 
with ASpace functionality? How did you resolve it?


I'm happy to provide more details if needed.


Thank you,


-Alan Huebschen

Brookens Library Information Systems

University of Illinois Springfield
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] [EXTERNAL] Re: Apache/httpd interfering with ASpace functionality

[Huebschen, Alan M]

Hi Blake,


I have checked the apache logs, browser dev console, and archivesspace.out for 
some sort of related error messages but there is nothing. Nothing has appeared 
in the httpd log since hours before I started testing this morning. Nothing 
appears in the browser dev console when I attempt to click the 'Delete' button. 
I'm rather unsure how to troubleshoot this other than temporarily disabling 
SSL/TLS through apache and readding my config changes slowly.


-Alan



From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Blake 
Carver 
Sent: Wednesday, September 29, 2021 12:33 PM
To: Archivesspace Users Group
Subject: [EXTERNAL] Re: [Archivesspace_Users_Group] Apache/httpd interfering 
with ASpace functionality

Check your Apache logs for errors. Sounds like maybe it's some kind of issue 
there.
Also, check the browser devtools counsel for errors, they are likely to show up 
there too.
Also check the archivesspace.out log for errors, might be something in there.

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of 
Huebschen, Alan M 
Sent: Wednesday, September 29, 2021 1:06 PM
To: Archivesspace Users Group 
Subject: [Archivesspace_Users_Group] Apache/httpd interfering with ASpace 
functionality


Good morning,


I have recently been made aware of some issues with functionality in our 
ArchivesSpace instance. Users are unable to perform some tasks, such as use the 
"Delete" button to delete records. I have tested my dev and prod copies of 
ASpace against local and remote DBs. My dev instance works perfectly fine, it 
does not use Apache/httpd for SSL/TLS but our production instance does. When I 
bypass Apache/httpd on the production instance, all of the functionality issues 
vanish.


We are currently running ArchivesSpace v3.1.0 and just upgraded from v2.8.0. 
The issues began in v2.8.0 and remain after our upgrade to v3.1.0.


Has anyone else run into similar issues with Apache/httpd or Nginx interfering 
with ASpace functionality? How did you resolve it?


I'm happy to provide more details if needed.


Thank you,


-Alan Huebschen

Brookens Library Information Systems

University of Illinois Springfield
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group