Multipart_ID_numbering Issue

atzemaej

I just upgraded to the latest version of providence and most everything seems to be working fine. One odd issue has to do with the five-part labelling I use for the accession code of collection items. The first two parts are codes with a choice of given values, the third part is the year and the last two parts are serial, where the fifth part is also child_only as that part is only used for items that are part of or derived from other items. In the previous versions of CA this worked fine. Now, when I have all five parts, I get two error signs --- one in front of the second part (called qualification) saying that x is not a valid qualification, where x is actually the number of the fifth part and another sign in front of the next part, but without any text. This is what I have in multipart_id_numbering.conf for the five parts:

elements = {
type = {
type = LIST,
values = [OBJ, MUS, RSC, GEN],
default = OBJ,
width = 3,
editable = 1,
description = _(Type)
}
qualification = {
type = LIST,
values = [N, O, A, S],
default = N,
width = 2,
editable = 1,
description = _(Qualification)
}
year = {
type = YEAR,
width = 4,
editable = 1,
description = _(Year)
}
number = {
type = SERIAL,
width = 3,
description = _(Number),
editable = 1
}
subnumber = {
type = SERIAL,
child_only = 1,
width = 3,
description = _(Subnumber),
editable = 1
}
}

What is going on here?
Thanks,
Eisso

atzemaej

As a followup to my previous message, I would like to note that this odd behavior only occurs when the first four parts of a child are identical to the corresponding parts of a parent. Thus, for OBJ.N.2024.8.1 with parent OBJ.N.2024.8, the system objects that 1 is not valid for qualifier, even though it still saves all five parts. However, if I change any of the four parts of the child such that there is no item with the same first four parts for its id, everything is fine. For example, if I change OBJ.N.2024.8.1 to MUS.N.2024.8.1, where MUS.N.2024.8 does not exist, the error message goes away. This is behavior that did not occur in earlier versions, even though I am using the exact same multipart_id_numbering.conf file. It would appear that somehow the fifth part is glommed on to the second part and is ignored for sorting.
Eisso

monica

atzemaej Hi Atzemaej, I am unsure what is going wrong for you. It sounds like it's letting you save, just giving you a warning? Are you able to share a screenshot of the warning? I do notice in your example, the comma at the end of each element is missing, but this might have been a copy/paste issue.

The only thing I would suggest is changing your config to use the PARENT element at the front and all the others (with exception of the serial) become root_only = 1.

This means each record first inherits the ID from the parent record, then adds a serial to the end. Benefit of this, is you can have more than one level of child and it will keep adding another serial element for each level.

This is assuming of course that you want all chid records to inherit the parent id as the first element.

EG.

elements = {
	parent_id = {
		type = PARENT,
		description = _(Parent record id)
	},
	type = {
		type = LIST,
		values = [OBJ, MUS, RSC, GEN],
		default = OBJ,
		width = 3,
		editable = 1,
		root_only = 1,
		description = _(Type)
	},
	qualification = {
		type = LIST,
		values = [N, O, A, S],
		default = N,
		width = 2,
		editable = 1,
		root_only = 1,
		description = _(Qualification)
	},
	year = {
		type = YEAR,
		width = 4,
		editable = 1,
		root_only = 1,
		description = _(Year)
	},
	number = {
		type = SERIAL,
		width = 3,
		description = _(Number),
		editable = 1
	}
}

atzemaej

Hi Monica,
The comma between the elements does not seem to make a difference. More importantly, however, your suggestion worked. I did have to put child_only = 1 in the parent element so to not have an empty element show up in front for existing and new non-child records. Everything seems fine now, but I have to put in some more records to see if there are any other issues or not.
Thanks,
Eisso