Bug #5863

reference code displaying inconsistently in brief view (and not updated when settings change)

Added by Tim Hutchinson over 8 years ago. Updated almost 8 years ago.

Status:VerifiedStart date:10/23/2013
Priority:HighDue date:
Assignee:Jesús García Crespo% Done:

100%

Category:Repository
Target version:Release 2.1.0
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:

Description

(with 2.x)

See attached screen shot for a mix of reference codes, on the brief view:
- identifier only
- inherited reference code, but no country or repository code
- full inherited reference code

These are all legacy records, migrated from 1.x (and likely imported to begin with). When you edit a record, the reference code reverts to the core identifier. This seems to be the case whether or not inheritance is enabled.

For new records, I wasn't able to get the inherited reference code to appear (in the brief view), even with inherit reference code set to yes ... both via data entry and XML import.

Similarly, when I changed the delimiter, nothing changed in the brief view.

The reference code displays as expected in the full view and edit screen.

reference code soup.png (54.4 KB) Tim Hutchinson, 10/23/2013 08:57 PM


Related issues

Related to AtoM Wishlist - Feature #5171: Improve level of detail included in the AtoM search resul... New 06/03/2013
Related to Access to Memory (AtoM) - Bug #5615: Inherited reference codes appear in search results even w... Verified 09/20/2013
Related to Access to Memory (AtoM) - Bug #5851: Advanced search - search in identifier only returns exact... Duplicate 10/22/2013

History

#1 Updated by Dan Gillean over 8 years ago

  • Category set to Repository
  • Assignee set to Jesús García Crespo
  • Target version set to Release 2.0.2

Keeping this as a separate issue for its bugginess, but I'm also associating it with an open 2.1 issue for improving the stub record details included in the search/browse results (#5171). Thanks again for the information, Tim.

#2 Updated by Dan Gillean over 8 years ago

Report from Creighton Barrett in the User Forum, December 11 2013:

Hi there,

We've been batch importing more data into our AtoM 2.0 instance and found some funny behaviour with the reference codes.

Our admin settings are configured to not inherit the code because the XSLT we use to prepare the EAD for batch import merges the <unitid> with the <container> info to create new file-level <unitid> tags that appear in the Reference Code.

However, after rebuilding the index, we've noticed that the browse/search results do in fact inherit the reference codes, as well as the country and institution codes. We'd rather not have the country code and institution code there, but more importantly, this means that the collection-level <unitid> is repeated.

I know this was discussed recently, but I can't find the relevant thread about reference codes in 2.0. Any ideas? Is there something we should be doing when we rebuild the index after batch imports?

Thanks,

Creighton

https://groups.google.com/forum/#!msg/ica-atom-users/SMta0-F1QPY/0JkxolLLhgwJ

#3 Updated by Dan Gillean over 8 years ago

  • Priority changed from Medium to High

Further information from Creighton:

Just a follow-up to this question. It occurred to me after I posted that the country and institution code were not displaying before our most recent EAD batch import. But the collection-level reference code was displaying twice, which is what prompted the initial discussion about this.

Before the most recent import, I updated our repository profile and added the institution code. Then we did a batch import and rebuilt the index. That was when I noticed the country code and institution codes appearing in the search/browse results in addition to the inherited CollectionID. We're seeing:

Country Code Institution Code CollectionID-UnitID

I wonder if the data from the institution profile is somehow appearing in the reference codes now? It wouldn't be so bad if it was just the country and institution code, but we've configured our file-level unitIDs to include the collection ID so it's confusing to see the CollectionID twice. AtoM is also inserting a hyphen between the collectionID and the file-level unitID. It's as though the index is ignoring our configuration to not inherit reference codes.

#4 Updated by Tim Hutchinson over 8 years ago

There does seem to be a consistency in what I'm seeing - the incorrect inheritance seems to occur at lower levels, but not the top level (fonds or series as highest level).

I have a hunch this is related to #5615 which I originally reported as only affecting 1.x. I think I was wrong, at least I'm now able to reproduce that behaviour in 2.x. Perhaps I was only getting fonds level results when I tested before.

#5 Updated by Tim Hutchinson over 8 years ago

Creighton, if I've understood your comment about the institution profile, note that the institution code is an expected part of the inheritance.

#6 Updated by Tim Hutchinson over 8 years ago

I rebuilt the search index with inheritance ON. Same thing - seems to be no inheritance at the top level, but correct at the lower levels.

#7 Updated by Dan Gillean over 8 years ago

Thanks for the notes, both of you. I hope this is an issue we can get to in 2.0.2. Radda, is there a way to see if the fix for #5615 was ever merged into 2.x - and if not, if we can merge it? If it already has been merged, then we need to revisit this issue in the code.

#8 Updated by Dan Gillean over 8 years ago

FYI it looks likely that the 1.x fix for #5615 will be merged into the 2.0.1 release. So if that doesn't resolve the issue, we'll know we have to revisit this. I have a feeling there will be outstanding issues...

#9 Updated by Tim Hutchinson over 8 years ago

My guess is that the top-level inherited reference code is specific to 2.x and will need to be checked separately, since the process for building the search index has (I gather) changed so significantly; and that doesn't seem to be an issue in 1.3.1.

#10 Updated by Creighton Barrett over 8 years ago

Thanks Tim! Sorry if it wasn't all that clear - I meant that the country and institution codes only started (incorrectly) appearing after we built the repository profile. Prior to building the profile, we just noticed the inherited collection ID.

I just checked and noticed, like Tim pointed out, that the incorrect inheritance only occurs at the lower levels. Top-level results don't include the country and institution codes.

Hopefully we'll do the upgrade to 2.0.1 soon, so we'll see if the fix for #5615 did the trick!

#11 Updated by Tim Hutchinson over 8 years ago

Hi Creighton - That makes sense; the country code and institution code are both pulled from the institutional profile. It looks like the fix didn't quite make it into 2.0.1.

#12 Updated by Creighton Barrett over 8 years ago

Ahh well! When I brought this up with one of our developers she thought it might be fixable (hidable?) via the php. But I didn't realize there was a related issue in the 1.x branch and maybe there's more to it than I realized when I explained the issue. Anyway, I'll update here if we make any progress.

#13 Updated by Tim Hutchinson over 8 years ago

For your reference, here's the 1.x commit:
https://github.com/artefactual/atom/commit/dfcc41534dce7731dfbbd33e93121e3e45941981
There's a little more to it - in 1.x a value was added to the search index. As opposed to generating the reference code on the fly, which I guess would have performance implications. I'm not sure where that's done in 2.x.

#14 Updated by José Raddaoui Marín over 8 years ago

  • Status changed from New to QA/Review
  • Assignee changed from Jesús García Crespo to Dan Gillean
  • % Done changed from 0 to 100

AtoM|commit: 1417015ba29dbe21f92838e0ed249f331077d88a

The search index needs to be rebuilt.

#15 Updated by Dan Gillean over 8 years ago

  • Status changed from QA/Review to Verified
  • Assignee changed from Dan Gillean to Jesús García Crespo

The reference code inheritance should be fixed with this issue. Tim, I know you are fond of pulling in updates to your local test environment and testing, so if you find anything that doesn't work as expected, let me know!

Creighton, just to clarify: Tim is correct, the inheritance of the country code and the institution code is an expected behaviour when the inheritance is set in Admin > Settings. The country code is drawn from the the country selected in the contact area of the ISDIAH record, and the institituional code from the institution ID also in the ISDIAH record. If you want to inherit reference codes but you don't want the country and repo ID to be present, you will have to find a local solution.

#16 Updated by Creighton Barrett over 8 years ago

This is excellent, thanks folks! Dan, it may not have been clear from my earlier description of this, but we don't have inheritance turned on in Admin > Settings so we were not expecting to see the country code and institution code. It was just an observation that the two codes started inheriting (in addition to the collection IDs) after we created the repository profile, which I guess is what should happen. Anyway, great to see the fix!

#17 Updated by Dan Gillean almost 8 years ago

  • Target version changed from Release 2.0.2 to Release 2.1.0

Also available in: Atom PDF