Private and public collection-specimen-OTU cascade fix

[doricon]

Currently any node can be designated public vs private. After testing, we learned that if you have a public node with dependent nodes that are private (e.g., public specimen but a private collection), two major things happen: (1) the workbench edit and delete options break completely for users without access to the private information. An "Error :(" message appears on the form instead of the selection box. (2) in explorer, when you try to render the page for the public node (in this example specimen), you simply get an error since a required node is private.

Solutions: (1) for Specimen, require that for a specimen to become public, the collection belongs to has to be public. (2) for OTU, the holotype needs to be public for the OTU to be public. It is ok for other specimens to be private as long as one specimen, the holotype, is public.

p.s., downstream non-required things don't seem to matter here, which is as it should be. For example, a private description on a public specimen.

[NoisyFlowers]

Specimens should inherit group membership from their Collection.

This was implemented once (April-ish) but group selection snuck back in with some other changes. I again have removed it.

This is in paleobot/pbot-client@7ab11c2b7752cda8eaa11a2d91cb9f606327ec48

[doricon]

Just want to verify two things since this was closed:

(1) That we can have a public collection but some specimens from it can still be private. (this will happen as people continually work on and publish specimens that were from the same site)

(2) And that for an OTU to become public, that the holotype should be public.

[NoisyFlowers]

I only addressed the bug that was causing the api error.

Group membership of Specimen nodes cannot be set independently. It is inherited from the Collection they belong to. We must have decided this at some point, because there is actually quite a bit of code in the api server that handles this from back in April. I just broke it at some point between then and now with some changes in the client. That is now fixed.

If we want to set Specimen group membership separately from Collection, this will be a much bigger deal. Will likely have to drop the requirement that a Specimen be in a Collection. Not sure. Definitely a major undertaking with more discussion required.

There is currently no logic that syncs Specimen group membership with OTU group membership. I tried a configuration in which holotype specimen was private while OTU was public, and, while perhaps not a desirable combination, it does not cause an error. Adding sync logic for this will also be a bigger deal.

I would suggest opening enhancement requests for these two items if they are desired.

[aazaff]

So… I don’t see why a specimen should really ever need to be private, particularly if the collection is public. Perhaps a user might want a DESCRIPTION of the specimen to be private, but that is something else entirely.

From: NoisyFlowers @.> Date: Wednesday, July 26, 2023 at 9:51 AM To: paleobot/pbot-dev @.> Cc: Zaffos, Andrew - (azaffos) @.>, Assign @.> Subject: [EXT]Re: [paleobot/pbot-dev] Private and public collection-specimen-OTU cascade fix (Issue #138)

External Email

I only addressed the bug that was causing the api error.

Group membership of Specimen nodes cannot be set independently. It is inherited from the Collection they belong to. We must have decided this at some point, because there is actually quite a bit of code in the api server that handles this from back in April. I just broke it at some point between then and now with some changes in the client. That is now fixed.

If we want to set Specimen group membership separately from Collection, this will be a much bigger deal. Will likely have to drop the requirement that a Specimen be in a Collection. Not sure. Definitely a major undertaking with more discussion required.

There is currently no logic that syncs Specimen group membership with OTU group membership. I tried a configuration in which holotype specimen was private while OTU was public, and, while perhaps not a desirable combination, it does not cause an error. Adding sync logic for this will also be a bigger deal.

I would suggest opening enhancement requests for these two items if they are desired.

— Reply to this email directly, view it on GitHubhttps://github.com/paleobot/pbot-dev/issues/138#issuecomment-1652176708, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACPQSQY5ARC3FAHVF3HOKILXSFDKNANCNFSM6AAAAAAZ7NRD6U. You are receiving this because you were assigned.Message ID: @.***>

[doricon]

Ok, I totally see your point Andrew about specimens not really needing to be private (particularly for a public collection) - what could someone possibly do with that super basic specimen info??! As long as the description can be private, or the image can be private, then it should be fine. (and maybe it will just have to be fine since Doug said it would be A LOT more complicated to have specimen and collection group membership separated).

The error for the OTU and specimen public/private issue only occurs for people who are NOT in the private group. To the user who created the private record (and any others in their private group) there will be no error, for all other users their OTU lookup abilities will be crashed. We can hop on and test that real quick together if needed to verify.

[doricon]

Following on my above message, I can open an enhancement request for the OTU and holotype specimen logic for later, and for the hackathon we will just train accordingly so that no one screws it up! And if someone does, at least we understand it and how to go fix it.

[aazaff]

The error for the OTU and specimen public/private issue only occurs for people who are NOT in the private group. To the user who created the private record (and any others in their private group) there will be no error, for all other users their OTU lookup abilities will be crashed. We can hop on and test that real quick together if needed to verify.

Okay, thinking about this more deliberately, what we REALLY need is to have an error pop up when people try to make an OTU public with private specimens. This will prevent what you are describing.

Putting programming aside entirely and just focusing on it from a scientific perspective, people should not be able to assert the existence of an OTU based on secret/hidden evidence.

[doricon]

Full agree Andrew! And I think and error message pop up would be a great way to do it.

I think it's fine for people to assign private non-type specimens to an existing public OTU as they are working on new stuff pre-publication (like I found new specimens in my locality that I think belong to Ellen's published OTU). But a new public OTU should definitely not be possible without its data/evidence being public!