search

spawaskar-cora / cora-docs

CoRA Docs
MIT License
36 stars 5 forks source link

Error when trying to add new specimen (CIL 2003-116 G-38 X-244A 103) #611

Open clegarde opened 4 years ago

clegarde commented 4 years ago

Receiving an error message of "Specimen add unsuccessful" when trying to add a new specimen. @aschaefer1 was trying to add and getting the error, so then I tried, also unsuccessful. She was able to add other new specimens with different information.

Steps to reproduce the behavior:

  1. Go to "Specimens" on left menu
  2. Click on 'New'
  3. Add following data: -> Accession: CIL 2003-116 -> Prov1: G-38 -> Prov2: X-244A -> Designator: 103 -> Bone: Unidentified cranium -> Side: Unsided -> Completeness: Incomplete
  4. Click 'Save'

  5. See error

    • Microsoft Edge 42.17134.1098.0

*Can't attach screenshot

SachinPawaskarUNO commented 4 years ago

Is this in CAT or PROD?

clegarde commented 4 years ago

PROD

SachinPawaskarUNO commented 4 years ago

@clegarde Looks like there is a specimen with the same composite key already in the project which has a soft delete. Can you not use another composite key which is unique (maybe change the designator? If not we may have to discuss how to handle this scenario?

clegarde commented 4 years ago

I also tried to add as designator 104 and it didn't work. However, if there is no 103 in the project, then we want to use it. Even if it was previously in use and subsequently deleted. I think this would be a common thing - re-using numbers that were previously deleted.

SachinPawaskarUNO commented 4 years ago

@clegarde and @fedamann 104 is also a soft deleted specimen. BTW 105 is available.

Delete is a destructive operation, hence we do a soft delete. In case someone does it inadvertently we can reverse it. Same things applies to the associations records for that deleted specimen. What you are proposing is allowing a hard delete. This can be done as a privileged operation by the Org Admin or someone, but we will have to discuss this as it may fly against the the needs of auditing & tracking and because the specimen in question (being deleted) may have several associations within CoRA and to other external systems. Again I advocate using another designator and I think this is something we need to discuss in person. We also need to see why do we have so many soft deleted specimens, Maybe looking into this might help us uncover hidden issues, maybe there is a training issue, or a feature that needs to be built out to change one field from being made editable instead of having to do a soft delete in the first place.

fedamann commented 4 years ago

I know this is hard to get around for the Oklahoma because of how it started but I think we need to move projects toward incremental designators rather than binning designators by bone type. Perhaps even consider auto-incrementing the designator for every new inventory record created per project. There is a certain beauty and simplicity when an inventory starts at 1 then proceeds to 2, and so on.

On Wed, Mar 4, 2020, 14:47 Sachin Pawaskar notifications@github.com wrote:

@clegarde https://github.com/clegarde and @fedamann https://github.com/fedamann 104 is also a soft deleted specimen. Delete is a destructive operation, hence we do a soft delete. In case someone does it inadvertently we can reverse it. Same things applies to the associations records for that deleted specimen. What you are proposing is allowing a hard delete. This can be done as a privileged operation by the Org Admin or someone, but we will have to discuss this as it may fly against the the needs of auditing & tracking and because the specimen in question (being deleted) may have several associations within CoRA and to other external systems. Again I advocate using another designator and I think this is something we need to discuss in person. We also need to see why do we have so many soft deleted specimens, Maybe looking into this might help us uncover hidden issues, maybe there is a training issue, or a feature that needs to be built out to change one field from being made editable instead of having to do a soft delete in the first place.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spawaskar-cora/cora-docs/issues/611?email_source=notifications&email_token=AC6TSM7ZLNC3RPSW3DOBXWDRF246VA5CNFSM4LBNWBHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEN2FZLQ#issuecomment-594828462, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC6TSM6ZXQLZER46ZEBASO3RF246VANCNFSM4LBNWBHA .

SachinPawaskarUNO commented 4 years ago

@fedamann I really like what you have suggested above "There is a certain beauty and simplicity when an inventory starts at 1 then proceeds to 2, and so on". This was exactly what was brought up by Nick Herman from Texas State University when I was discussing the Eleon project in Greece. I think we need to create an auto-incrementing designator feature in CoRA, with a controlling flag setting at the project level.

clegarde commented 4 years ago

@fedamann @SachinPawaskarUNO . I agree that incremental designators are a good way to go. That is not what this is about, and if anything, makes my point for me. If we can't re-use designators, and we're using incremental designators, then we might have 1, 2, 3, 4, 7, 8, 9, 11, etc. Seems weird. We don't delete that often, and it is usually because it never should have been in CoRA. If possible, we edit the designator or other data. I think CoRA has enough checks and balances that it is difficult to inadvertently delete something. You have to click edit, then delete, and doesn't it ask if you're sure? That's a lot of accidental clicks. If we're worried about it, I think we could make it something that only Admin and/or Project Managers can delete, like with the DNA samples numbers. Like I said, it doesn't happen that often.