Bug #5914

Create a second accession in the same day in a culture different than 'en' gives "500 Internal Server Error."

Added by José Raddaoui Marín over 8 years ago. Updated about 7 years ago.

Status:VerifiedStart date:11/05/2013
Priority:HighDue date:
Assignee:Dan Gillean% Done:

0%

Category:Accessions
Target version:Release 2.2.0
Google Code Legacy ID: Tested version:1.3.1, 2.2
Sponsored:No Requires documentation:

Description

QubitAccession_getAccessionNumber_fix_bug5914.php Magnifier (432 Bytes) Edgar Rodríguez Silva, 01/23/2014 03:36 AM

History

#1 Updated by Dan Gillean over 8 years ago

Additional information from the user who reported the issue:

I tried altering the accession number mask and it worked. Although not as you expected but with a slight difference.
Using today's date, I altered only the incremental part of the mask as follows "%Y-%m-%d/1". The result was an accession number "2013-11-08/1".

In this case the software didn't decreased the number presented in the creation form, as it does when the incremental is on (#1) rather then a fixed number (1 in this case).

Afterwards I altered the mask to it's original formula (%Y-%m-%d/#i) to see what the incremental would do. Since I had no accession number "2013-11-08/0", the mask created the number "2013-11-08/1" in the "create accession form", and after saving the result was an accession "2013-11-08/0".

I don't know where the accession number incremental is calculated to input into the database, but it seems that at least part of the problem may be there.
I hope this helps you to analyse the problem.

#2 Updated by Dan Gillean over 8 years ago

  • Priority changed from Medium to High

There has recently more reports of this affecting users in the community - see this user forum discussion ( https://groups.google.com/d/msg/qubit-dev/va7JDowGvY8/3U-05Y6a7MAJ ), and a related issue ticket discussion on #6202, which was marked invalid and moved here.

#3 Updated by Tim Hutchinson over 8 years ago

The bug seems to boil down to the accession counter (on the settings form) not being updated correctly.

A workaround to make things work in a different language - but not multiple languages - is to change the source_culture field corresponding to name=accession_counter in the settings table.

#4 Updated by Edgar Rodríguez Silva over 8 years ago

Tim, I have tested the workaround. It works fine for the source_culture in the name=accession_counter in the settings table, but fails for any other. I changed to gl the source_culture, and now fails in English, for example.

#5 Updated by Tim Hutchinson over 8 years ago

Hi Edgar - Right, sorry if that wasn't clear. Unfortunately the workaround only applies to a single language; if you need to switch languages within a single AtoM instance, you would need a fix for the underlying problem.

#6 Updated by Edgar Rodríguez Silva over 8 years ago

I have isolated the problem and I have a solution proposal. The malfunction is provoked by the function "QubitAccession::getAccessionNumber" and the inappropiate way of setting accession_counter.

Basically, there are this problems:
- always getting the accession_counter value for default_culture, not for the context culture. Then the accession_counter for the culture in context never grows up isolated.
- accession_counter value of context culture is saved with accession_counter of default culture +1 but never is used to make new identifier.
- When we solve the precedent problems, still remains one. The identifier is constructed with one number, then if accession_counter for default culture and others cultures are the same in one day they can crash producing the same identifier.

Solution:
- Use the accession_counter for the context culture incrementing and saving it.
- Add the culture code into the identifier to verify that it never is the same than with other culture.

I attach one file with the new function.

#7 Updated by Dan Gillean over 8 years ago

Edgar, this is great! Thank you so much for looking into this issue. I hope to have Jesus review the patch soon, and perhaps deploy it in a testing branch for us - Jessica, our other Product Manager, is currently undertaking a comprehensive review of all multilingual and culture issues in AtoM so we can file new tickets and try to address these issues throughout the application. We will both be very interested to test your patch, and hopefully incorporate it into AtoM very soon. Unfortunately at the moment our developers are very busy with client projects, so it might take a bit before we can address this as we want - but we are really excited to receive your contribution. More news soon - and thanks again!

#8 Updated by Tim Hutchinson over 8 years ago

Edgar, I'm curious about your use case for supporting multiple languages in a single instance. Do you have one institution using more than one language, or multiple institutions?

The reason I'm asking is that I'd also be interested in functionality to improve the ability for multiple institutions to use the accessions module - so in particular I'm wondering if tying the counter to institution rather than culture would address both issues.

In terms of this specific bug, I'm a little leery about explicitly adding culture to the identifier - I wonder if tracking the counter independent of culture would work? Or increment all cultures' counters?

#9 Updated by Edgar Rodríguez Silva over 8 years ago

In our region we have two official languages. Use multiple languages is one requeriment.

I think if you tie the counter to institution rather than culture you will have the same issue. You have to differentiate for example one counter with value 12 in "Institution A" to other counter with value 12 in "Institution B".

I think the best solution would be using only one counter, do not tie to culture nor institution. For us explicitly adding culture is not leering, but sincerelly I don't like it so much. You can substitute the language code for a less explicit code, e.g. en = 00, es = 01...

#10 Updated by Jesús García Crespo over 7 years ago

  • Target version changed from Release 1.4.0 to Release 2.1.1
  • Tested version 1.3.1 added

#11 Updated by Jesús García Crespo over 7 years ago

  • Target version changed from Release 2.1.1 to Release 2.2.0

#12 Updated by José Raddaoui Marín over 7 years ago

  • Status changed from New to Code Review
  • Assignee changed from José Raddaoui Marín to Jesús García Crespo

Created PR: 104

Now the counter is always saved and obtained in the source culture of the setting, no matter in what culture is the interface.

#13 Updated by Jesús García Crespo over 7 years ago

  • Status changed from Code Review to QA/Review
  • Assignee changed from Jesús García Crespo to José Raddaoui Marín

It looks good to me, Radda. If you have some extra time I'd like to see that read+update happening within a transaction. We should have transactions everywhere, but we don't! It would be exceptionally convenient here to avoid concurrency issues when incrementing the counter. Take a look at beginTransaction, but I'm not sure if it'll work. If the ORM is broken at this point maybe we should just do it with raw SQL, see https://dev.mysql.com/doc/refman/5.1/en/commit.html.

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

  • Status changed from QA/Review to Code Review
  • Assignee changed from José Raddaoui Marín to Jesús García Crespo

#15 Updated by Jesús García Crespo over 7 years ago

  • Status changed from Code Review to Feedback
  • Assignee changed from Jesús García Crespo to José Raddaoui Marín

Radda is going to test if the transactions are for real with general_log enabled (MySQL). I am not positive about it hehe

#16 Updated by José Raddaoui Marín about 7 years ago

  • Status changed from Feedback to Code Review
  • Assignee changed from José Raddaoui Marín to Jesús García Crespo

Looks like it's working.

7984 Query    SELECT term_i18n.NAME, term_i18n.ID, term_i18n.CULTURE FROM `term_i18n` WHERE term_i18n.ID='326'
7984 Query SELECT slug.SLUG
FROM slug
WHERE '326' = slug.OBJECT_ID
7984 Query START TRANSACTION
7984 Query SELECT setting.NAME, setting.SCOPE, setting.EDITABLE, setting.DELETEABLE, setting.SOURCE_CULTURE, setting.ID, setting.SERIAL_NUMBER FROM `setting` WHERE setting.NAME='accession_counter' LIMIT 1
7984 Query UPDATE setting_i18n SET `VALUE`='2', `ID`='50' WHERE setting_i18n.ID='50' AND setting_i18n.CULTURE='en'
7984 Query commit

7984 Query INSERT INTO object (`CLASS_NAME`,`CREATED_AT`,`UPDATED_AT`) VALUES ('QubitAccession','2015-03-12 03:41:53','2015-03-12 03:41:53')
7984 Query INSERT INTO accession (`ID`,`DATE`,`IDENTIFIER`,`CREATED_AT`,`UPDATED_AT`,`SOURCE_CULTURE`) VALUES ('432','2015-03-12','2015-03-12/2','2015-03-12 03:41:53','2015-03-12 03:41:53','en')

#17 Updated by Jesús García Crespo about 7 years ago

  • Status changed from Code Review to Feedback
  • Assignee changed from Jesús García Crespo to José Raddaoui Marín

Cool cool!

#18 Updated by José Raddaoui Marín about 7 years ago

  • Status changed from Feedback to QA/Review
  • Assignee changed from José Raddaoui Marín to Dan Gillean

#19 Updated by Dan Gillean about 7 years ago

  • Status changed from QA/Review to Verified
  • Tested version 2.2 added

Accession will now count incrementally regardless of culture. Tested by creating 2 accessions in English, switching to French, creating 2 more accessions, switching back to English and creating another one, then switching to Dutch and creating 2 more. No issues encountered.

Also available in: Atom PDF