reference code displaying inconsistently in brief view (and not updated when settings change)
|Assignee:||Jesús García Crespo||% Done:|
|Target version:||Release 2.1.0|
|Google Code Legacy ID:||Tested version:|
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.
#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:
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?
#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.
#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.
#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!
#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:
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.
#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!