Unique Identifiers not generating correctly

[Mark Johnson]

Following an upgrade to 2.7 I have received reports from users that

"Atom has not been generating unique ID numbers. The date changes, but each record is created with the suffix _7116 e.g. 2023-07-10_7116. Attempts to edit the record by clicking “generate identifier” have not changed the data."

Is this a known issue, or is there some new configuration required we might be missing?

[Dan Gillean]

Hi Mark, 

That is strange and quite specific - I do not recall hearing reports of this previously. Have you double-checked the identifier mask setting to make sure that someone didn't accidentally hardcode _7116 into the mask? See: 

• https://www.accesstomemory.org/docs/2.7/user-manual/administer/settings/#identifier-mask
  

If you are using a date as part of the mask, you will definitely need an incrementing counter at the end to avoid collisions. The number of i elements included in the mask should determine this - so:

• %Y-%m-%d/#i should produce 2023-07-11/1, while
  
• %Y-%m-%d/#iii should produce 2023-07-11/001
  

But if the mask reads %Y-%m-%d/_7116, then every record will have _7116 appended to the identifier. 

Let us know what you find! 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/444e5443-4e1a-4655-848c-91a30d55989cn%40googlegroups.com.

[Mark Johnson]

Hi Dan,

Thanks for responding

I looked in Settings and saw the identifier mask enabled was 'No', I assume this setting must have been reset during the upgrade. I have enabled it and the settings now show as attached

whenever I trigger the request /informationobject/generateIdentifier I always get the following

{"identifier":"2023-07-12_7117"}

the front part of it does change, i.e if I try tomorrow it will now be 2023-07-13_7117 but the latter part does not. I manually changed it from 7116 to 7117 but that made no difference.

Additionally I see I dont have any logs -

 qubit_cli.log

 qubit_worker.log

 qubit_prod.log

exist but have no entries

I also find that /usr/share/nginx/atom/apps/qubit/config/factories.yml does not exist, I tried adding it manually. assigning it to www-data and restarting services, but it doesnt seem to have had any impact.

Any other pointers?

Cheers,

Mark

[Dan Gillean]

Hi Mark, 

Sorry for the delay - I've been trying to figure out a good answer for you, but so far talking to the developers hasn't turned up any obvious issue or path forward based on the information we have currently. 

First the logs - I wouldn't worry too much about it. We have never relied on Symfony itself for logging, and if you have no factories file at /apps/quibit/config, then AtoM will use the default one in /config instead. It can really depend on how you install and deploy your instance. 

Regarding the identifier counter: 

• Are you trying to use the counter while creating new descriptions, or to edit / update existing descriptions? There is a known issue that you could be encountering - see #13632. Similarly, at present the setting will not automatically apply to imported descriptions, nor will the counter auto-increment to account for other descriptions that may have been created - this is one of the reasons we make the counter editable, so it can be manually incremented when needed. 
• Was it working fine until it reached this higher number? Though the developers tell me there is no set upper limit they can find in the code, Symfony itself has some known quirks that are difficult to track down, and it's possible that the framework is somehow interfering here. There is slightly similar issue with trying to set Symfony's timeout limit setting, for example. 
• Do all the numbers NEED to have consecutive incrementation, even if the date prefix will be different? I'm wondering if you could try resetting the counter to 1 at the end of a day, for example, to see if it works again with lower counter values
• Barring that, have you tried changing the mask at all? For example, using a dash instead of an underscore before the incrementing value etc. Alternatively, since your number is quite high, does it make any difference if you use #iiii (rather than just #i) for the incrementing value?

I did a quick test in the public demo site, which is currently running 2.7.1-192. Unfortunately, I wasn't able to reproduce the issue with a quick test. I did the following: 

• Navigate to Admin > Settings > Identifiers
• Enable the Identifier Mask
• Change the mask to %Y-%m-%d_#i
• Manually set the identifier counter to 7117, and save my settings changes
• Create a new description - confirm identifier is 2023-07-17_7117 on save
• Create a second description - confirm identifier is 2023-07-17_7118
• Try changing mask to use #iiii instead of #i, and save
• Create a third new description - confirm identifier is 2023-07-17_7119

Is there anything unique about your AtoM installation? i.e. Have you made any changes from the default installation instructions (i.e. PHP, MySQL, or Elasticsearch version; different webserver, etc...)? Does your site have any local code customizations, including a custom theme? If no custom theme, are you using the older classic Bootstrap 2 Dominion theme (the default), or the new Bootstrap 5 version introduced in the 2.7 release? Anything else unique or different we should know?

Finally, what is the full AtoM version number listed in Admin > Settings?

Hopefully with a bit more information, we can figure out next steps. Thanks! 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/a6116138-4cd1-4336-9e1a-65015f39e667n%40googlegroups.com.

[Mark Johnson]

Thanks Dan, 

that information was useful, 

The version is "2.7.1 - 192"

"Are you trying to use the counter while creating new descriptions, or to edit / update existing descriptions? There is a known issue that you could be encountering - see #13632. Similarly, at present the setting will not automatically apply to imported descriptions, nor will the counter auto-increment to account for other descriptions that may have been created - this is one of the reasons we make the counter editable, so it can be manually incremented when needed"

I have now established it IS  successfully incrementing for new archival descriptions, it seems the issue is isolated to generating new identifiers for existing descriptions - as per  #13632. I will let the users know about this, do you know if there any plan to fix this issue in the short-medium term, or is it on the back burner?

Kind Regards,

Mark

[Dan Gillean]

Hi again Mark, 

I'm glad we have at least identified the issue! 

The version is "2.7.1 - 192"

Ok, great. Version 192 is the correct / expected database schema version for the 2.7.x releases, so no upgrading steps were skipped. 

I have now established it IS  successfully incrementing for new archival descriptions, it seems the issue is isolated to generating new identifiers for existing descriptions - as per  #13632. I will let the users know about this, do you know if there any plan to fix this issue in the short-medium term, or is it on the back burner?

Our Maintainers are in the process of defining the scope of the 2.8 release and preparing a release plan. They are currently collecting tickets, reports, wish list items, and other priorities from other teams at Artefactual who interact with AtoM users, from which they will define the final release roadmap. I have added #13632 to this shortlist so it will be considered for the next release, though I cannot guarantee it will be included.

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/ed7aa43b-f4eb-46a9-a96a-83eaa054acafn%40googlegroups.com.

[Mark Johnson]

Thanks Dan, I'll keep my eye on upcoming releases

[Mark Johnson]

Hi Dan,

So it transpires that identifier autoincrement also breaks when the Duplicate button is used after a new record is created, after which, when adding new records the identifier will not increment until it is manually edited in admin settings. Needless to say the institution I am representing are quite unhappy about this, as it is quite disruptive and confusing, especially for non technically minded users. We would like it escalated, will the Atom maintainers commit to a fix in the not so distant future?

Regards,

Mark

[Dan Gillean]

Hi Mark, 

First, I've not been able to reproduce this issue as you describe on our demo site. If you are able to recreate it there, I would encourage you to file a bug ticket in the AtoM code repository, here: 

• https://github.com/artefactual/atom/issues/new/choose
  

It's very helpful for us to know more about the specific environment where the issue was reproduced, as well as detailed steps on how to reproduce it, so that we can properly recreate the issue, diagnose it, and determine next steps. If you'd like, here is an example of a recent ticket I filed to give you a sense of details that help our Maintainers. If you're unable to reproduce the issue in our demo site or another vanilla test instance of AtoM, then tell me more about these particular installations - for example: 

• Does the site meet the recommended minimum technical requirements for a production site?
• Did the installation follow the recommended installation instructions for the version (for example - for 2.7.x, using Linux Ubuntu 20.04, PHP 7.4, MySQL 8.0, Elasticsearch 5.6, Nginx as the web server, etc)? If no, what has been changed?
• Does the site include any custom code, including a custom theme?
• etc

Additionally, I cannot promise that a fix for this particular issue, should we be able to reproduce it and identify it as a bug, be included in the next release. Our Maintainers determine what issues and enhancements to prioritize based on their own triage process, which prioritizes the needs of our paying hosted and enterprise clients. 

If you would like to see the issue prioritized, there are two ways you might aid in doing so: first, if your company has developers, you could prepare your own patch and submit it as a pull request to the public project. We have developer resources on our wiki to help get you started here, including contributing guidelines and community development recommendations. 

Alternatively, as you seem to be a service provider using AtoM with your clients, you might contact Artefactual off-list (in...@artefactual.com) to see what support or partnership options we can offer. 

Otherwise, we value bug reports and community feedback, and will continue to review open issues and address what we can with each public release we freely make available to our community of users. 

Regards, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/00ac524f-1e43-4799-bab7-d166cb8967dfn%40googlegroups.com.