Bug #12718

Actors associated with non-creation event types linked to descriptions should still display in the name access points field, and be available in the Names facet on description browse/search pages

Added by Dan Gillean almost 2 years ago. Updated 22 days ago.

Status:FeedbackStart date:01/16/2019
Priority:MediumDue date:
Assignee:Mike Cantelon% Done:

0%

Category:Actor
Target version:Release 2.6.0
Google Code Legacy ID: Tested version:2.4, 2.5
Sponsored:No Requires documentation:

Description

First reported in the User forum, 2019-01-12: https://groups.google.com/d/msg/ica-atom-users/jzk559vb4RY/A8bf4U-CCQAJ

Reproduced locally in 2.4.0 demo site and 2.5.x vagrant box.

Summary

It's possible to add non-creation events in a couple ways in AtoM:
  • If you are using the RAD template
  • If you add non-creation events in a CSV import
  • If you create the actor-resource relation from the authority record page in the Relationships area
  • If you import an Events CSV with a descriptions CSV import

However, in most cases, the only place this relationship is shown with a hyperlink is in the right-hand context menu / sidebar. This can make it difficult for end users to find the relations from the description view page.

Additionally, these names do not show up in the Names facet, which is currently only showing direct relations when a name access point is added. It would be nice if users were able to facet on these results as well.

Background

In feature #10048 we introduced pagination for the actor relations shown in the left-hand context menu of authority records. One unintended side effect was that a long-standing behavior in AtoM (to automatically add any creator as a subject access point, with no option for users to remove just the access point) that was suppressed in the user interface was suddenly made visible, and we got a lot of feedback about this. Most importantly, users pointed out that there are many cases where the creator of the records is not actually the subject of the records at all, and that we shouldn't automate this assumption and not give users a way to undo it.

In light of this, we implemented a change in 2.4.1, in issue #11828. With this change, now actors associated with events are no longer automatically added to the name access points area.

One side effect is that when other event types are present, the relation is only visible in the list of names shown in the right-hand context menu (the one exception is RAD - though the associated actor names will appear in the Dates of creation area, they are not hyperlinked). This present a usability issue for those who want to highlight other events associated with descriptions.

It should be possible to re-add the automatic inclusion of these relations to the name access points area without undoing the change in #11828 that prevents this from happening for creators. Hopefully, we can modify the Names facet to include any actor relations that are not creators as well.

Test 1 - visibility of non-creator relations in description view pages

To reproduce

  • Use the ISAD template by default
  • Navigate to an existing authority record and enter edit mode
  • In the Relationships area, click to add a new related resource
  • Select an existing description from the resource drop-down
  • Select an event type that is not creation (i.e. reproduction, distribution, broadcasting, etc)
  • Add dates if desired (not required for the test)
  • Submit the modal, and then save the authority record
  • Navigate to the newly linked description

Error encountered

  • It's difficult to find the relation (it's only listed in the right-hand context menu)
  • The relation does not appear anywhere in the body of the record

Expected result

  • Event relations (between actors and information objects) that are not creation events should appear listed in the Name access points area. Users will still need to go to the related Actor page to remove them (or flip the template to RAD), but they will at least be more visible and usable.

Test 2: ability to find other actor relation names in the Names facet

To reproduce

  • Repeat the steps for test 1 with the same actor, until it has enough relations to appear in one of the top 10 results shown in a facet
  • Navigate to the archival description search/browse page
  • Attempt to facet based on the related actor's name

Issue encountered

  • Non-creation relations are not included in any facet
  • It is not possible to search or facet on these relations

Expected result

  • Users can facet results based on names that include non-creation event type relations

booth-example-broadcaster.png (239 KB) Dan Gillean, 12/18/2019 11:48 AM

eventActors-test2-relationDuplication.mp4 - video showing the issue described in notes 5 and 8 (5.87 MB) Dan Gillean, 09/28/2020 10:05 AM

actor-event-relation-duplication-2020-09-28.png - new screenshot showing the actor relation duplication (56.3 KB) Dan Gillean, 09/28/2020 10:05 AM


Related issues

Related to AtoM Wishlist - Feature #12719: Allow users to qualify name access points using non-creat... New 01/16/2019
Related to Access to Memory (AtoM) - Bug #13266: Descriptions not indexed on search:populate task Verified 02/23/2020
Related to AtoM Wishlist - Feature #13424: Improve visibility of non-creation actors in the RAD temp... New 09/28/2020
Related to Access to Memory (AtoM) - Bug #13425: Adding multiple event actors on the fly in the RAD templa... New 09/28/2020

History

#1 Updated by Dan Gillean almost 2 years ago

  • Related to Feature #12719: Allow users to qualify name access points using non-creation events added

#2 Updated by Dan Gillean over 1 year ago

Note: if we ever implement the work, there are some related considerations to take into account.

First, Radda thinks that right now, non-creation event actors can't even be searched on archival descriptions - we are only saving the actor_id rom other events in the dates field of the ES index. We might want to consider indexing these as additional names (which would go with the request in the ticket above to have these actors show up in the names facet on search/browse pages).

Additionally, we would need to consider the job scheduler task that manages updates when actors are edited - it will need tweaking for when and how it is triggered.

#3 Updated by Mike Cantelon 11 months ago

  • Status changed from New to Code Review

#4 Updated by Mike Cantelon 10 months ago

  • Status changed from Code Review to QA/Review

Merged into qa/2.6.x.

#5 Updated by Dan Gillean 10 months ago

  • Status changed from QA/Review to Feedback
  • Assignee set to Mike Cantelon
  • Target version set to Release 2.6.0

This is looking great, and a major improvement!

I noticed just one minor strange behavior it would be good to fix if possible, when following test 1 above:

If you add an actor relation to a description using a different event type (e.g. Broadcast), then 2 things happen on save:

1) The relation does not show up on the actor page on save, unless you do a hard refresh - might we need to clear the application cache as part of the save process?
2) Once it does show up, the actor is listed as both a subject and broadcaster - even though the relation was only for broadcast, and on the related description they are only listed as a broadcaster (which is the desired outcome).

I've attached a screenshot to try to show what I mean. I'm more concerned about addressing 2 than 1, but fixing both would be great if possible!

Steps to reproduce

  • Navigate to an authority record and enter edit mode
  • In the Relationships area, open the modal to add a new description relationship
  • Select a different fonds/collection in the description relationships modal, and add a Broadcast relationship. Save.
  • Save the authority record

Error encountered

  • Once the authority record is saved, the new relation is not immediately visible - user must do a hard refresh for it to display. Possible caching issue.
  • After refreshing the page to make the new description relation visible, the actor/description relation is shown in the left-hand context menu as both "Subject of" and "Broadcaster of"

Expected outcome

  • The new relation is visible on the actor view page immediately after saving the authority record
  • The new Broadcast relation is only shown in the left context menu as "Broadcaster of" (not also "Subject of")

#6 Updated by Dan Gillean 10 months ago

Oops, attaching screenshot

#7 Updated by Dan Gillean 7 months ago

  • Related to Bug #13266: Descriptions not indexed on search:populate task added

#8 Updated by Dan Gillean 22 days ago

Update, re-tested 2020-09-28 in qa/2.x (2.7 development):

The hard refresh is no longer required, but the actor relation to the description is still duplicated. See the attached screenshot, and a video demoing the issue

#9 Updated by Dan Gillean 22 days ago

  • Related to Feature #13424: Improve visibility of non-creation actors in the RAD template added

#10 Updated by Dan Gillean 22 days ago

  • Related to Bug #13425: Adding multiple event actors on the fly in the RAD template can cause the link to the authority record to be lost on save added

Also available in: Atom PDF