search

arch-kiosk / arch-kiosk-office

💼 central place for collaboration
GNU Affero General Public License v3.0
1 stars 0 forks source link

Off by one error in survey creation - identifier number starts at 2 instead of 1 #716

Closed SamKimball-BrownU closed 3 years ago

SamKimball-BrownU commented 4 years ago

So, on Alice, the assigned survey numbers are 1-9. When I created my first survey, however, it started at survey 02. I think this is an error. However, it seemed that it worked for logsipad (survey unit 40)? so I don't know. Maybe I accidentally pressed the button twice., but I don't think so. I can't really go back and test without starting from a completely blank database. I will do some further tests tomorrow, once we are all synced up, so that if I empty the database there will be no worries about actually losing data.

urapadmin commented 4 years ago

Be extra suspicious about those numbering things because we have never used them in the field! I need that database to look at it. Have you uploaded that one already? (And not uploaded a newer version since? Please don't!)

lbestock commented 4 years ago

Yes, everyone uploaded and we are synchronized and up to date.

urapadmin commented 4 years ago

ok, I do know, why this happened: Nuri's NA1 has 1 as the local id. (local ids are used in the background to build sequences or to store what id from a numbering list is already in use. If somebody wants to know more about it the wiki might help: https://www.meritaten.net/urapdev/doku.php?id=manuals:developer_manual:context_identifiers&s[]=numbering&s[]=method).

When Sam's id was created the system found "1" being already used as a local id and so it chose the next number from the list. What I do not know is WHY Nuri's NA1 has 1 as the local id because excavation units are configured to be free input and free input does not create local ids at all (no other excavation unit in the project has a local id). I can imagine that when that unit was created the method / unit type was changed before the final identifier was put in. So the first identifier might have been created with a different numbering function and that left the local id 1 in there. A wild guess. Can somebody shed light on it?

Also: Why does Nuri's unit NA1 have a particular identification method for contexts? One that is usually used for features? Was this unit an object of demonstration or experimentation?

What I do learn from this, anyhow, is that if a system uses a mix of numbering functions that all use the local id, they interfere in ways that are hard to explain. I'll think about that part. But I can't currently think of a good solution.

But I would want to understand how the 1 in Nuri's case happened at all. That could be a different bug or phenomenon.

urapadmin commented 4 years ago

please remember to mark your tickets as "filemaker". It helps me a lot not to overlook them.

urapadmin commented 4 years ago

can somebody elucidate the history of the creation of this unit NA1? Is it possible that it got its identifier generated or renamed or some such before it ended up being called NA1 manually?

nvd2 commented 4 years ago

Hi If I remember correctly I meant to name the unit NA, but when I was naming it I added a 1 to the end accidentally. I don't recall any other name being generated beforehand. Nuri

On Jul 14, 2020, at 6:30 PM, urapadmin notifications@github.com wrote:

 can somebody elucidate the history of the creation of this unit NA1? Is it possible that it got its identifier generated or renamed or some such before it ended up being called NA1 manually?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe.

lbestock commented 4 years ago

Going back through this because it's related to a new ticket, #741. While it's possible for a user to change ID methods for context, collected material, and analysis, it isn't really possible to do so for unit identification. Not while logged in as NVD, at least, so the name with its 1 really must have been created while it was free input.

urapadmin commented 4 years ago

perhaps. But I cannot reconstruct what happened here. We have to run into the issue again in a more reproducible way.

luizaogs commented 3 years ago

@urapadmin -- is there something to be done here other than trying to reproduce this issue (and is that what we should try to do)?

urapadmin commented 3 years ago

it is one of those really longish threads. Honestly, I don't think we have a chance to reproduce that outside of a similarly extensive project. Needs more people making more chaos.

urapadmin commented 3 years ago

One would need a field season. Even I wouldn't mind.

urapadmin commented 3 years ago

I'd say, let's close it. Closed.