CA 2.09 Autonumbering fails

remco

Setup: Shared server Collective Access 2.09

Adding a new object record the object ID is initially showing the next value correctly (for instance 00053). After saving the object the id number is 00001 (which is a duplicate ID number) where it should be 00053.
My multipart_id_numbering.conf for objects is:
ca_objects = { __default__ = { separator = , elements = { coll_num = { type = LIST, values = [_RU, SKU, KUN, UMC, T2O], default = UMC, width = 3, description = Collectie code, editable = 1, }, item_num = { type = SERIAL, width = 5, zeropad_to_length = 5, description = Item number, editable = 1, table = ca_objects, field = idno, sort_field = idno_sort, }, item_sub = { type = FREE, width = 8, description = Item subnumber or letter, editable = 1, table = ca_objects, field = idno, sort_field = idno_sort, }, }, },

remco

If I change my code for the code in the manual the difference is that no correct suggestion is made before save, After save with this code I also get a duplicate number.
It seems to be an issue in the source code rather than in my code for multipart_id_numbering.conf.

remco

If I am right the suggested number is generated by another piece of code (js/ca.idnochecker.js) than the code that saves the number. Could that be right?

monica

remco did you already have records with idno in the system when you set your idno rules? Most of the time, the serial won’t work correctly if there are already numbers in there, or one that was manually edited with the incorrect format. Auto numbering looks at the numbers already there and picks the next, if any go against the format, it reverts back to one.

If you’ve had this rule all along and it just started not working, then check the manually edited serial number elements. Someone might have put a letter into it something.

remco

The system worked with (basically) these autonumbering rules for years. I made some adaptions about 6 months ago, but the autonumbering still worked as expected.
This was with version CA1.8.
Last week we upgraded to CA2.09.
Now after saving it saves the wrong number. The suggestion before save has the correct expected number so I assume at least part of my multipart_id_numbering.conf can generate the expected result.
I have a test system with exactly the same setup so I can test and confirm there are no typo's or things like that.

remco

I did change the file BaseModelWithAttributes.php. a few weeks ago to get Batch edititing to work. (see
https://support.collectiveaccess.org/d/302156-collective-access-209-batch-editing-error-with-source-access-checking )
I reverted that and cleared the cache to see if that had any effect, but it did not (other than batch editing not working) so I set it back to the changed file.

seth

Make sure you update all sort values. Run caUtils rebuild-sort-values

remco

I did clear the cache, update sort values, search index and hierarchy after every change.
The weird thing is that autonumbering does work on movements, loans and occurences.
They have the same structure.

remco

Are the sort values related to the search index?
In my (and in the standard) search_indexing.conf the field idno_sort is not indexed.

seth

Sort values are completely separate.

There are hidden fields for preferred labels (titles) and identifiers that have the content from their visible counterparts reformatted so they can be sorted to user expectations by the database. The sortable formatting has changed over time to reflect new requirements. If your identifiers aren't sorry correctly, the next-in-sequence numbering may be affected. Thus the suggestion to regenerate those values.

remco

I think I am on to something.
The formatting for movements, loans and occurences is missing the third element (item_sub).
I tried both (with and without) the third element for objects.
This code does not work

ca_objects = {
default = {
separator = ,
allow_extra_elements=1,
extra_element_width=8,
elements = {
coll_num = {
type = LIST,
values = [_RU, SKU, KUN, UMC, T2O],
default = UMC,
width = 3,
description = Collectie code,
editable = 1,
},
item_num = {
type = SERIAL,
width = 5,
zeropad_to_length = 5,
description = Item number,
editable = 1,
},
item_sub = {
type = FREE,
width = 8,
description = Item subnumber or letter,
editable = 1,
},
},

},

}

And this code works

},

}

Another slightly annoying issue is that the default value for the LIST items in no longer working as it did.
I have formatting for objects of different types with a different default value for the LIST. This used to work fine but stopped working now.

remco

Sorry, somehow the formatting for the code got lost.

remco

With this code the default value for the LIST items is also working.

__default__ = {
			separator = ,
                        allow_extra_elements=1,
                        extra_element_width=8,
                        sort_order = [coll_num, item_num],			
			elements = {
				coll_num = {
					type = LIST,
					values = [_RU, SKU, KUN, UMC, T2O], 
					default = UMC, 
					width = 3, 
					description = Collectie code,
                                        editable = 1,
				},
                                item_num = {
					type = SERIAL,
					width = 5,
                                        zeropad_to_length = 5,
					description = Item number,
					editable = 1,
					table = ca_objects,
					field = idno,
					sort_field = idno_sort,
				},
			},                        
		},

The difference is that I have now sort_order, table, field and sort_field added.
Adding an extra element still breaks autonumbering. I have tried this for FREE and for ALPHANUMERIC.