Closed urapadmin closed 2 years ago
Found the first two bugs:
I ran into the same two bugs immediately. Does it have something to do with configuration? I went to try to configure this for PVD with the thought in my head that this more than photos is going to be a change for URAP: how do I get it so that URAP numbers are applied across categories of CM given that these are now three separate things? Can I have FA-001-1 (ceramics bulk) FA-001-2 (golden statue) FA-001-3 (ceramics bulk) FA-001-4 (C14 sample)? I was going to see if I could figure out how. But identification in configuration so far only has the ability to apply methods to CM, not to small finds and samples. See now #1509 for that issue.
The creation of the bulk "do you really want to" only happens if the bulk ID method is configured in the S'Urachi way, not if I configure it as serial CM number. The small find bug remains. Also having done that first configuration I answered my question about URAP numbering positively.
"back to developer" means -> the developer is on it.
I ran into the same two bugs immediately. Does it have something to do with configuration? I went to try to configure this for PVD with the thought in my head that this more than photos is going to be a change for URAP: how do I get it so that URAP numbers are applied across categories of CM given that these are now three separate things? Can I have FA-001-1 (ceramics bulk) FA-001-2 (golden statue) FA-001-3 (ceramics bulk) FA-001-4 (C14 sample)? I was going to see if I could figure out how. But identification in configuration so far only has the ability to apply methods to CM, not to small finds and samples. See now #1509 for that issue.
if I understand you correctly, you just missed out on the new "collected material types" button under admin. That's where you configure the cm type identification methods from now on
You understood me correctly.
@arch-kiosk/test: for all to test
Is this the small find error you were referring to? If so I am still getting it when trying to create a small find (though I am not sure if this is because configuration is currently weird, since I haven't tried to configure anything).
Wait, that must be configuration. The identifier in the error is a bulk one. So potentially ignore that.
Ok I am going to leave the configuration part to Laurel because I am confusing myself and getting nowhere. But once I changed all of the identification methods (small find, sample, and bulk) to the normal cm numbering in PVD I was able to create them all no problem, and the information per tab matches that of the specs above.
I'm getting a very similar error in a couple cases. I first created a bulk find in a context. I played around with it and added a photo and everything seems to be working as expected. However, when I went to add a small find, it prompted me to choose a material, but when I tapped the check on that window, I got this error:
I then tried to make a sample find, was once again prompted to choose a material which I did, but got the same error when I confirmed the choice.
Creating another bulk item caused the same exact error. Is it possible I did something to screw up the automatic counting up that I assume should happen when a new item is created? I am not comfortable messing with configuration, so I don't know if that would change anything.
PVD has not been configured in any reasonable way for collected material numbers so far. That's where these messages come from. This is a s'Urachi number coupled with remains from former projects. Before anybody can test this properly the configuration has to be done first (I thought that should be part of the test): @lbestock: PVD needs configuration and some testing coordination.
okay, we needed a coherent configuration of identification methods to test anything. So here it is:
record type | what id should be generated |
---|---|
excavation unit | when creating an excavation unit free input is on |
feature unit | when creating a feature a serial number is generated depending on the identifier list 'feature numbers'. The number has three digits and will have an F as a prefix |
survey unit | when creating a survey unit a serial number is generated depending on the identifier list 'survey numbers'. The number has three digits and will have an S as a prefix |
locus | three digit number based on unit, so something like FA-001 |
hidden locus in feature or survey | automatically created, rarely seen. But it is just the same number the unit itself uses. So the hidden locus for F001 is called F001 |
bulk | no matter what type of unit, bulk is created on the basis of the locus and just adds a material code to the locus number. Something like FA-001B would be the result if B is for animal bones. The result must be a unique identifier |
small find | no matter what type of unit, small finds add a serial number to the locus number. Something like FA-001-1 or in feature units it would be F001-1. The result must be a unique identifier |
samples | no matter what type of unit, samples add a serial number to the UNIT identifier. Something like FA-1 would be the result. Note that samples and small finds would share the same number sequence currently in feature units. FA-1 can be a small find or a sample. No way to tell from the identifier itself. |
s'Urachi style ceramic fragments | still as usual: would be something like SU2013-FA-001-1-001 in PVD, I guess. |
Ok, now that PVD is configured I believe this is working. But see #1528 for a bulk-related question.
Same with #1528. Also, the material menu no longer pops up when creating a sample or small find. I thought it did before, but maybe I'm wrong.
Also, the material menu no longer pops up when creating a sample or small find. I thought it did before, but maybe I'm wrong.
that is correct. The material selection is used only for bulk while small find and samples are using different identification methods (see list above). And yes, it did before because the configuration was a muddle and collected material generally used the same identification method. That there are three now is one of the news here.
I'd like @lbestock to test this, too, before we close it.
I just close this.
@test recording 12.3 / kiosk 0.17
coming out of #1489 (where you find some additional instructive information, perhaps):