Agreed. We have 5GB for ArchivesSpace but we rarely touch even close to
that except for really big jobs like generating PDFs of some of our massive
finding aids (1k+ pages). We have 4 processors available but, again, with a
lot of breathing room. That stated, we don't use the PUI.
On Tue, Sep 29,
That's more than enough for any site. 1/2 that is more than enough for most
sites.
(I'm assuming Linux, not Windows)
If you're having problems with crashes with that much power behind your site,
there might be something wrong.
From:
Hi all!
Will those who maintain your own on-site instance of ArchivesSpace share
the memory specifications of your server?
Ours is:
16 GB ram, 11 GB assigned to AS. 6 cores (processors)
My very best,
Jessika
*Jessika Drmacich *
*Records Manager & Digital Resources Archivist *
*Williams
Steve, all:
It looks like it does cause an issue for the PUI PDFs, as well, at least with
an example that I just tested thanks to Maura Carbone, who provided a sample
bit of text to try (hi, Maura!). See:
http://test.archivesspace.org/repositories/2/archival_objects/3909.
When I tried the
Yes, a sample would be useful to try to reproduce the issue. It would also be
interesting to know if both the staff PDF export and the PUI PDF show the same
problems. — Steve M.
> On Sep 29, 2020, at 11:42 AM, Custer, Mark wrote:
>
> Dear Hitomi Matsuyama,
>
> Which version of
David is totally correct. Not related to the public user at all as I had
initially speculated.
I wonder why some of the get endpoints never got specific permissions? At a
minimum I think they should all be 'view_repository' but that might have some
other consequences downstream.
Joshua
I was able to find the endpoints in the list by searching for
".permissions([])", for example in
archivesspace/backend/app/controllers/agent_family.rb:
Endpoint.get('/agents/families')
.description("List all family agents")
.params()
.paginated(true)
.permissions([])
I think this is an unintended consequence of the PUI.
In
https://github.com/archivesspace/archivesspace/blob/master/backend/app/model/group.rb
there is a PUBLIC_GROUP_CODE which is name 'publicanonymous' which is granted
view_repository rights - presumably so that the PUI can function.
I'm
I'm curious if this has always been the case, as well, but it would seem like
it has been. I knew that the repository and location endpoints could be
accessed but didn't try any of the rest for some inexplicable reason. Not good
to have agent contact details available that way.
Given which
That's a *very* interesting find! I had naively believed the docs that
indicated that most of the endpoints required authentication without actually
trying to bounce off a random endpoint without a token.
The controllers indicate that there should be permissions involved and that
they should
Dear Hitomi Matsuyama,
Which version of ArchivesSpace are you using?
I'm not familiar with those configuratio settings, but I suspect that they
might just be for the PDF formats of the Reports, not for the PDF format of the
EAD conversion process.
On newer releases of ArchivesSpace, the
I've been investigating providing access to the ArchivesSpace RESTful API
to an expanded group of users.
Through testing, it appears that many of the RESTful API endpoints (see
below) do not require user authentication (i.e., do not require a "session"
key), and access apparently cannot be
Hi All-
I've created a git repo that describes our Docker setup. I hope it'll be enough
to get people going, but please feel free to send me an email with questions.
https://github.com/dartmouth-dltg/aspace-docker
Joshua
From:
Hello all,
We've had some trouble with PDF export in Japanese.
Descriptive information written with Japanese characters, hiragana,
katakana, and kanji, are not exported to ArchivesSpace formatted
finding-aids at all.
Our IT staff has tried to modify config.rb as follows in order to add some
14 matches
Mail list logo
