ArctosDB / arctos

Arctos is a museum collections management system
https://arctos.database.museum
60 stars 13 forks source link

Immediate clone of record & associated privileges #1721

Closed DerekSikes closed 3 years ago

DerekSikes commented 6 years ago

Issue Documentation is http://handbook.arctosdb.org/how_to/How-to-Use-Issues-in-Arctos.html

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

We often use the immediate clone feature to create 'perfect' duplicates of records (something the clone via the bulkloader fails to do, and also does slowly - those clones in the BL need to be loaded later by admin, delaying work flow of students).

So first - making immediate clones is something I'd like lab techs who can edit specimens to be able to do without needing to give them any special more powerful privileges.

And 2nd - very often we make immediate perfect clones of specimens because we have multiple specimens from the same collection event that differ only in their identifications (but the specimens are being handled and databased by our lab techs at different times - often weeks or months apart). So when a clone is made we need to delete the prior identification because that (new) specimen's ID is not correct (and shouldn't even be in the ID history since that specimen had never been ID'd as that taxon).

Describe the solution you'd like A clear and concise description of what you want to happen.

Move the ability to make immediate clones & deletion of identifications to manage_specimen privileges.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Currently I grant manage_collection access to my lab techs so they can do these things but this gives them powers I'd rather they not have (except for the above).

Additional context Add any other context or screenshots about the feature request here.

Priority I would like to have this resolved by date: ___

dustymc commented 6 years ago

This would introduce a minor inconsistency: specimens could be created by manage_collection (eg, by approving things in the bulkloader, as now) and by manage_specimens via the clone option. I'm OK with that, but we should be explicit here and there should be documentation.

campmlc commented 6 years ago

I support this also. The tool says that the insert is immediate with no review, but perhaps we should clarify to "a new specimen record is cloned and inserted directly into the collection. This process bypasses the bulkloader and does not allow for manage collection review prior to load. Use only with curatorial approval. Accidentally created records must be deleted using encumbrances."

On Thu, Oct 4, 2018 at 3:21 PM dustymc notifications@github.com wrote:

This would introduce a minor inconsistency: specimens could be created by manage_collection (eg, by approving things in the bulkloader, as now) and by manage_specimens via the clone option. I'm OK with that, but we should be explicit here and there should be documentation.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1721#issuecomment-427173872, or mute the thread https://github.com/notifications/unsubscribe-auth/AOH0hJOABkmVEqcvUl9p--EYzunDMN41ks5uhnvwgaJpZM4XI4Lv .

dustymc commented 3 years ago

Elevating priority for https://github.com/ArctosDB/internal/issues/77

GUIDs come with a significant curatorial commitment, and creating them is arguably one of the most important things we do. I'm somewhat inclined to argue that manage_collection should remain the minimum amount of access required to create a record, that doing so is essentially managing the collection.

I could be convinced that we need a new role somewhere between 'manage_specimen' and 'manage_collection,' something that allows access to bulk tools and record creation perhaps. Collections that see those roles as part of the same thing could just grant both, those who don't can grant them incrementally (or not at all, or whatever).

I'm of course ultimately happy to do whatever The Community wants, but I do think this access needs careful consideration.

A "Use only with curatorial approval." announcement is no substitute for a security model, particularly as we think about APIs in which "we" would have no control of the UI.

DerekSikes commented 3 years ago

this sounds good to me

"I could be convinced that we need a new role somewhere between 'manage_specimen' and 'manage_collection,' something that allows access to bulk tools and record creation perhaps"

-D

On Fri, Jan 15, 2021 at 11:41 AM dustymc notifications@github.com wrote:

Elevating priority for ArctosDB/internal#77 https://github.com/ArctosDB/internal/issues/77

GUIDs come with a significant curatorial commitment, and creating them is arguably one of the most important things we do. I'm somewhat inclined to argue that manage_collection should remain the minimum amount of access required to create a record, that doing so is essentially managing the collection.

I could be convinced that we need a new role somewhere between 'manage_specimen' and 'manage_collection,' something that allows access to bulk tools and record creation perhaps. Collections that see those roles as part of the same thing could just grant both, those who don't can grant them incrementally (or not at all, or whatever).

I'm of course ultimately happy to do whatever The Community wants, but I do think this access needs careful consideration.

A "Use only with curatorial approval." announcement is no substitute for a security model, particularly as we think about APIs in which "we" would have no control of the UI.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1721#issuecomment-761186422, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACFNUM2SGFO43RJIWQQPNNTS2CR6HANCNFSM4FZDQLXQ .

--

+++++++++++++++++++++++++++++++++++ Derek S. Sikes, Curator of Insects Professor of Entomology University of Alaska Museum University of Alaska Fairbanks 1962 Yukon Drive Fairbanks, AK 99775-6960

dssikes@alaska.edu

phone: 907-474-6278 FAX: 907-474-5469 he/him/his University of Alaska Museum - search 400,276 digitized arthropod records http://arctos.database.museum/uam_ento_all http://www.uaf.edu/museum/collections/ento/ +++++++++++++++++++++++++++++++++++

Interested in Alaskan Entomology? Join the Alaska Entomological Society and / or sign up for the email listserv "Alaska Entomological Network" at http://www.akentsoc.org/contact_us

campmlc commented 3 years ago

I support this.

On Fri, Jan 15, 2021 at 2:12 PM DerekSikes notifications@github.com wrote:

  • [EXTERNAL]*

this sounds good to me

"I could be convinced that we need a new role somewhere between 'manage_specimen' and 'manage_collection,' something that allows access to bulk tools and record creation perhaps"

-D

On Fri, Jan 15, 2021 at 11:41 AM dustymc notifications@github.com wrote:

Elevating priority for ArctosDB/internal#77 https://github.com/ArctosDB/internal/issues/77

GUIDs come with a significant curatorial commitment, and creating them is arguably one of the most important things we do. I'm somewhat inclined to argue that manage_collection should remain the minimum amount of access required to create a record, that doing so is essentially managing the collection.

I could be convinced that we need a new role somewhere between 'manage_specimen' and 'manage_collection,' something that allows access to bulk tools and record creation perhaps. Collections that see those roles as part of the same thing could just grant both, those who don't can grant them incrementally (or not at all, or whatever).

I'm of course ultimately happy to do whatever The Community wants, but I do think this access needs careful consideration.

A "Use only with curatorial approval." announcement is no substitute for a security model, particularly as we think about APIs in which "we" would have no control of the UI.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1721#issuecomment-761186422, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ACFNUM2SGFO43RJIWQQPNNTS2CR6HANCNFSM4FZDQLXQ

.

--

+++++++++++++++++++++++++++++++++++ Derek S. Sikes, Curator of Insects Professor of Entomology University of Alaska Museum University of Alaska Fairbanks 1962 Yukon Drive Fairbanks, AK 99775-6960

dssikes@alaska.edu

phone: 907-474-6278 FAX: 907-474-5469 he/him/his University of Alaska Museum - search 400,276 digitized arthropod records http://arctos.database.museum/uam_ento_all http://www.uaf.edu/museum/collections/ento/ +++++++++++++++++++++++++++++++++++

Interested in Alaskan Entomology? Join the Alaska Entomological Society and / or sign up for the email listserv "Alaska Entomological Network" at http://www.akentsoc.org/contact_us

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1721#issuecomment-761199841, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBFEJ22ZNIGQAGK6XMLS2CVUZANCNFSM4FZDQLXQ .

dustymc commented 3 years ago

Sounds like a consensus to me...

Suggestions for the role name? Format manage_xxxxx would make it consistent, but that's not critical. It's easy to adjust what the role does, but the name should be around ~forever.

mkoo commented 3 years ago

manage_clone is free

On Fri, Jan 15, 2021 at 4:37 PM dustymc notifications@github.com wrote:

Sounds like a consensus to me...

Suggestions for the role name? Format manage_xxxxx would make it consistent, but that's not critical. It's easy to adjust what the role does, but the name should be around ~forever.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1721#issuecomment-761274562, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATH7UKO2JLPYASU5UIYEGTS2DNVNANCNFSM4FZDQLXQ .

dustymc commented 3 years ago

It's important to somehow convey the critical information that this role will minimally have INSERT on cataloged_item. Even if we don't intend other methods of doing that, someone will use the API or https://github.com/ArctosDB/internal/issues/77 will happen; It should be expected that users will find a way to do whatever the DB allows.

Secondarily, perhaps this would (eventually) be used for things like DELETE on Identification or other "assistant collections manager" type things, whatever they may be.

campmlc commented 3 years ago

"Data Management" ? "Curatorial" ? "Manage Curation" ?

Jegelewicz commented 3 years ago

manage_records

dustymc commented 3 years ago

manage_records

Going, going,...........................

dustymc commented 3 years ago

...........gone.

New role will allow:

INSERT on cataloged item/minting guids, for this (also requires a form change)

INSERT UPDATE DELETE on all cftemp... (component loader) tables for https://github.com/ArctosDB/arctos/issues/3657

(Note: relaxed access also requires rebuilding the loader to v1.4 and setting access in the template)

At least for now, this will be a subset of manage_collection - nothing here isn't also there, there's no reason to assign this to users who have manage collection, we may want to revisit that at some point.