[Archivesspace_Users_Group] How records show up on internet searches

[Anderson, Freya N (EED)]

Hello all

We’ve been doing some sample searches to see how our records show up in Google 
and other search engines.  We’re glad that they’re showing up in the results, 
but the page names that show up bold at the top of the listings are generic, 
with no information about the actual collection they refer to.  For example, 
from a Google 
result:<%0dHistorical%20Collections%20Finding%20Aids%20-%20Alaska%20State%20Library%0dhttps:/alaska.libraryhost.com%20›%20repositories%20›%20resources%0d>
Historical Collections Finding Aids - Alaska State 
Library<%0dHistorical%20Collections%20Finding%20Aids%20-%20Alaska%20State%20Library%0dhttps:/alaska.libraryhost.com%20›%20repositories%20›%20resources%0d>
https://alaska.libraryhost.com › repositories › 
resources<%0dHistorical%20Collections%20Finding%20Aids%20-%20Alaska%20State%20Library%0dhttps:/alaska.libraryhost.com%20›%20repositories%20›%20resources%0d>

Exxon Valdez Papers, 1987-1990. Guides and documents accompanying the 104 Video 
Recordings (AV 025) related to the Exxon Valdez oil spill, 1989-1991, ...

Is there any way for us to set this up so that the actual content, in this case 
“Exxon Valdez Papers, 1987-1990” shows up in the top line?  It seems like it 
would be a lot more user friendly that way.

As you can probably see from the URL, we’re using a hosted version of 
ArchivesSpace.

Thanks!
Freya


[cid:image001.png@01D507DF.8CCD64B0]
Freya Anderson (she/her)
Head, Information Services
Acting Head, Historical Collections
phone: 907.465.1315

Andrew P. Kashevaroff Building
Mail: PO Box 110571, Juneau, AK 99811
Visit: 395 Whittier St., Juneau, AK 99801

email | web |  
sign up for event 
notifications | The 
Information Center for Government


___
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

[Detelich, Alicia]

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 

Date: Friday, October 11, 2019 at 11:52 AM
To: "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

--

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

[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

Re: [Archivesspace_Users_Group] Creating location records - how?

[Nick Butler]

Hi Dan,

Many thanks for the clarification - clearly haven't quite got my head around 
this enough yet!

Best wishes,
Nick

-Original Message-
From: Daniel Michelson 
mailto:daniel%20michelson%20%3cdmichel...@smith.edu%3e>>
Reply-To: Archivesspace Users Group 
mailto:archivesspace%20users%20group%20%3carchivesspace_users_gr...@lyralists.lyrasis.org%3e>>
To: Archivesspace Users Group 
mailto:archivesspace%20users%20group%20%3carchivesspace_users_gr...@lyralists.lyrasis.org%3e>>
Subject: Re: [Archivesspace_Users_Group] Creating location records - how?
Date: Fri, 11 Oct 2019 07:52:26 -0400

Hi Nick,

Since locations are shared across repositories, users only need permissions 
from one repository.

This is also true of all other shared records, such as agents and subjects.

Hope this helps.

Dan

On Fri, Oct 11, 2019, 5:53 AM Nick Butler 
mailto:np...@cam.ac.uk>> wrote:
Hi all,

Looking at this a little bit more, it seems to be the case that the 
"update_location_record" permission is given globally whilst the 
"manage_repository" permission is set at repository level. This means that if a 
user has managerial level permissions at repository A but only very basic level 
permissions at repository B, they are still able to create, amend and delete 
locations at both A and B.

Is there any reason that "update_location_record" isn't a repository level 
permission? We will have quite a number of repositories and a fair few staff 
members who will be given different permission levels in more than one of them. 
It just seems bizarre that someone who is merely in the "repository-viewers" 
group at a repository should be allowed to delete said repository's locations, 
purely because another repository has put them in the "repository-managers" 
group.

Best wishes,
Nick

-Original Message-
From: Nick Butler 
mailto:nick%20butler%20%3cnp...@cam.ac.uk%3e>>
Reply-To: Archivesspace Users Group 
mailto:archivesspace%20users%20group%20%3carchivesspace_users_gr...@lyralists.lyrasis.org%3e>>
To: 
archivesspace_users_group@lyralists.lyrasis.org
 
mailto:%22archivesspace_users_gr...@lyralists.lyrasis.org%22%20%3carchivesspace_users_gr...@lyralists.lyrasis.org%3e>>
Subject: Re: [Archivesspace_Users_Group] Creating location records - how?
Date: Thu, 10 Oct 2019 15:06:43 +

Hi Trevor,

Thank you very much for your speedy and helpful response - giving the user the 
manage_repository permission did indeed fix the issue. I don't think I'd have 
found that file otherwise, and it looks like a useful point of reference.

Many thanks,
Nick

-Original Message-
From: Trevor Thornton 
mailto:trevor%20thornton%20%3ctrtho...@ncsu.edu%3e>>
Reply-To: Archivesspace Users Group 
mailto:archivesspace%20users%20group%20%3carchivesspace_users_gr...@lyralists.lyrasis.org%3e>>
To: Archivesspace Users Group 
mailto:archivesspace%20users%20group%20%3carchivesspace_users_gr...@lyralists.lyrasis.org%3e>>
Subject: Re: [Archivesspace_Users_Group] Creating location records - how?
Date: Thu, 10 Oct 2019 11:01:19 -0400

We just ran into this issue last week. From what I can tell, the permission to 
update location records is tied to the permission to manage the repository 
("manage this repository (change groups and other settings)"). I couldn't find 
any documentation to back this up but found this setting in the code:

https://github.com/archivesspace/archivesspace/blob/8ffdb952cce8c8804392c229772ae68a00065bcc/backend/app/lib/bootstrap_access_control.rb#L209-L212

On Thu, Oct 10, 2019 at 10:51 AM Nick Butler 
mailto:np...@cam.ac.uk>> wrote:
Hi all,

We're currently running v2.5.2 on our development system (we aren't live yet) 
and we're running into a peculiar problem with the permission 
"update_location_record".

As far as we can tell, two users have been set up with the same level of 
permissions yet only one can create and edit location records. Pulling their 
records via the [:GET] /users/:id API endpoint shows that one has the 
"update_location_record" for all their repositories and also for the 
"_archivesspace" global repository, yet the other doesn't have this permission 
anywhere. The full list of permissions acquired via the [:GET] /permissions 
endpoint doesn't even include this permission; nor does the permission table of 
our underlying database. I tried adding it to the other user's record by 
POSTing a modified user object to the [:POST] /users/:id endpoint but this 
seems to have had no effect.

Basically, how does one go about getting this permission? And is there a reason 
it doesn't show up in either the database or [:GET] /permissions? Could this be 
something that's resolved by upgrading from v2.5.2? Any advice would be very 
welcome, as this will become quite a pressing issue for us soon.

Many thanks,
Nick

--

Nick Butler
Software Developer
Digital Services
Cambridge University Library
West Road
Cambridge CB3 9DR, UK

Re: [Archivesspace_Users_Group] Creating location records - how?

[Daniel Michelson]

Hi Nick,

Since locations are shared across repositories, users only need permissions
from one repository.

This is also true of all other shared records, such as agents and subjects.

Hope this helps.

Dan

On Fri, Oct 11, 2019, 5:53 AM Nick Butler  wrote:

> Hi all,
>
> Looking at this a little bit more, it seems to be the case that the
> "update_location_record" permission is given globally whilst the
> "manage_repository" permission is set at repository level. This means that
> if a user has managerial level permissions at repository A but only very
> basic level permissions at repository B, they are still able to create,
> amend and delete locations at both A and B.
>
> Is there any reason that "update_location_record" isn't a repository level
> permission? We will have quite a number of repositories and a fair few
> staff members who will be given different permission levels in more than
> one of them. It just seems bizarre that someone who is merely in the
> "repository-viewers" group at a repository should be allowed to delete said
> repository's locations, purely because another repository has put them in
> the "repository-managers" group.
>
> Best wishes,
> Nick
>
> -Original Message-
> *From*: Nick Butler  >
> *Reply-To*: Archivesspace Users Group <
> archivesspace_users_group@lyralists.lyrasis.org
> 
> >
> *To*: archivesspace_users_group@lyralists.lyrasis.org <
> archivesspace_users_group@lyralists.lyrasis.org
> <%22archivesspace_users_gr...@lyralists.lyrasis.org%22%20%3carchivesspace_users_gr...@lyralists.lyrasis.org%3e>
> >
> *Subject*: Re: [Archivesspace_Users_Group] Creating location records -
> how?
> *Date*: Thu, 10 Oct 2019 15:06:43 +
>
> Hi Trevor,
>
> Thank you very much for your speedy and helpful response - giving the user
> the manage_repository permission did indeed fix the issue. I don't think
> I'd have found that file otherwise, and it looks like a useful point of
> reference.
>
> Many thanks,
> Nick
>
> -Original Message-
> *From*: Trevor Thornton  >
> *Reply-To*: Archivesspace Users Group <
> archivesspace_users_group@lyralists.lyrasis.org
> 
> >
> *To*: Archivesspace Users Group <
> archivesspace_users_group@lyralists.lyrasis.org
> 
> >
> *Subject*: Re: [Archivesspace_Users_Group] Creating location records -
> how?
> *Date*: Thu, 10 Oct 2019 11:01:19 -0400
>
> We just ran into this issue last week. From what I can tell, the
> permission to update location records is tied to the permission to manage
> the repository ("manage this repository (change groups and other
> settings)"). I couldn't find any documentation to back this up but found
> this setting in the code:
>
>
> https://github.com/archivesspace/archivesspace/blob/8ffdb952cce8c8804392c229772ae68a00065bcc/backend/app/lib/bootstrap_access_control.rb#L209-L212
>
> On Thu, Oct 10, 2019 at 10:51 AM Nick Butler  wrote:
>
> Hi all,
>
> We're currently running v2.5.2 on our development system (we aren't live
> yet) and we're running into a peculiar problem with the permission
> "update_location_record".
>
> As far as we can tell, two users have been set up with the same level of
> permissions yet only one can create and edit location records. Pulling
> their records via the [:GET] /users/:id API endpoint shows that one has the
> "update_location_record" for all their repositories and also for the
> "_archivesspace" global repository, yet the other doesn't have this
> permission anywhere. The full list of permissions acquired via the [:GET] /
> permissions endpoint doesn't even include this permission; nor does the
> permission table of our underlying database. I tried adding it to the other
> user's record by POSTing a modified user object to the [:POST] /users/:id
> endpoint but this seems to have had no effect.
>
> Basically, how does one go about getting this permission? And is there a
> reason it doesn't show up in either the database or [:GET] /permissions?
> Could this be something that's resolved by upgrading from v2.5.2? Any
> advice would be very welcome, as this will become quite a pressing issue
> for us soon.
>
> Many thanks,
> Nick
>
> --
>
> *Nick Butler*
> *Software Developer*
> *Digital Services*
> *Cambridge University Library*
> *West Road*
> *Cambridge CB3 9DR, UK*
>
> *np...@cam.ac.uk* 
>
> *Internal tel: 33067*
>
> ___
> 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
>
>
> --
>
> *Nick Butler*
> *Software Developer*
> *Digital Services*
> *Cambridge University Library*
> *West Road*
> *Cambridge CB3 9DR, UK*
>
> *np...@cam.ac.uk* 
>
> *Internal tel: 33067*
>
> 

Re: [Archivesspace_Users_Group] Creating location records - how?

[Nick Butler]

Hi all,

Looking at this a little bit more, it seems to be the case that the 
"update_location_record" permission is given globally whilst the 
"manage_repository" permission is set at repository level. This means that if a 
user has managerial level permissions at repository A but only very basic level 
permissions at repository B, they are still able to create, amend and delete 
locations at both A and B.

Is there any reason that "update_location_record" isn't a repository level 
permission? We will have quite a number of repositories and a fair few staff 
members who will be given different permission levels in more than one of them. 
It just seems bizarre that someone who is merely in the "repository-viewers" 
group at a repository should be allowed to delete said repository's locations, 
purely because another repository has put them in the "repository-managers" 
group.

Best wishes,
Nick

-Original Message-
From: Nick Butler 
mailto:nick%20butler%20%3cnp...@cam.ac.uk%3e>>
Reply-To: Archivesspace Users Group 
mailto:archivesspace%20users%20group%20%3carchivesspace_users_gr...@lyralists.lyrasis.org%3e>>
To: archivesspace_users_group@lyralists.lyrasis.org 
mailto:%22archivesspace_users_gr...@lyralists.lyrasis.org%22%20%3carchivesspace_users_gr...@lyralists.lyrasis.org%3e>>
Subject: Re: [Archivesspace_Users_Group] Creating location records - how?
Date: Thu, 10 Oct 2019 15:06:43 +

Hi Trevor,

Thank you very much for your speedy and helpful response - giving the user the 
manage_repository permission did indeed fix the issue. I don't think I'd have 
found that file otherwise, and it looks like a useful point of reference.

Many thanks,
Nick

-Original Message-
From: Trevor Thornton 
mailto:trevor%20thornton%20%3ctrtho...@ncsu.edu%3e>>
Reply-To: Archivesspace Users Group 
mailto:archivesspace%20users%20group%20%3carchivesspace_users_gr...@lyralists.lyrasis.org%3e>>
To: Archivesspace Users Group 
mailto:archivesspace%20users%20group%20%3carchivesspace_users_gr...@lyralists.lyrasis.org%3e>>
Subject: Re: [Archivesspace_Users_Group] Creating location records - how?
Date: Thu, 10 Oct 2019 11:01:19 -0400

We just ran into this issue last week. From what I can tell, the permission to 
update location records is tied to the permission to manage the repository 
("manage this repository (change groups and other settings)"). I couldn't find 
any documentation to back this up but found this setting in the code:

https://github.com/archivesspace/archivesspace/blob/8ffdb952cce8c8804392c229772ae68a00065bcc/backend/app/lib/bootstrap_access_control.rb#L209-L212

On Thu, Oct 10, 2019 at 10:51 AM Nick Butler 
mailto:np...@cam.ac.uk>> wrote:
Hi all,

We're currently running v2.5.2 on our development system (we aren't live yet) 
and we're running into a peculiar problem with the permission 
"update_location_record".

As far as we can tell, two users have been set up with the same level of 
permissions yet only one can create and edit location records. Pulling their 
records via the [:GET] /users/:id API endpoint shows that one has the 
"update_location_record" for all their repositories and also for the 
"_archivesspace" global repository, yet the other doesn't have this permission 
anywhere. The full list of permissions acquired via the [:GET] /permissions 
endpoint doesn't even include this permission; nor does the permission table of 
our underlying database. I tried adding it to the other user's record by 
POSTing a modified user object to the [:POST] /users/:id endpoint but this 
seems to have had no effect.

Basically, how does one go about getting this permission? And is there a reason 
it doesn't show up in either the database or [:GET] /permissions? Could this be 
something that's resolved by upgrading from v2.5.2? Any advice would be very 
welcome, as this will become quite a pressing issue for us soon.

Many thanks,
Nick

--

Nick Butler
Software Developer
Digital Services
Cambridge University Library
West Road
Cambridge CB3 9DR, UK

np...@cam.ac.uk

Internal tel: 33067

___
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


--

Nick Butler
Software Developer
Digital Services
Cambridge University Library
West Road
Cambridge CB3 9DR, UK

np...@cam.ac.uk

Internal tel: 33067

___

Archivesspace_Users_Group mailing list

Archivesspace_Users_Group@lyralists.lyrasis.org