Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let users set is_microsetta when creating a project but not alter it when updating #59

Merged
merged 1 commit into from
Oct 23, 2020

Conversation

AmandaBirmingham
Copy link
Collaborator

As @wasade points out, if an existing project has at least one existing kit, reclassifying that project from being a Microsetta project to not being one (or vice versa) requires some actions on the ag_kit and ag_kit_barcodes tables. The existing update_project functionality does not take these actions (and I am not entirely clear on what they should be), so in the short term, disable changing the is_microsetta field through the microsetta-admin gui when UPDATING a project's info. However, continue to allow setting this info through the gui when creating a NEW project.

@AmandaBirmingham
Copy link
Collaborator Author

@wasade, I'm curious as to what the correct behavior would be if one changed the is_microsetta setting for an existing project. To me it looks like:

  • If the project has no kits, then it's smooth sailing, of course--just change the is_microsetta field in the barcodes.project table.
  • If there is even one kit, and the project is changing from not microsetta to microsetta, then we can add new records for the existing kits/barcodes to the ag_kit and ag_kit_barcodes table (after inferring the number of samples per kit from what is already in the db).
  • If there is even one kit, and the project is changing from microsetta to not microsetta, we can just try to delete all the associated records in the ag_kit and ag_kit_barcodes table and hope like heck no one has actually done anything with them yet ... however, if any of the kits is connected to any scan/etc then I think the delete will fail bc of foreign keys; in that case do we just tell the user "sorry, too late, you can't do that now"?

@wasade
Copy link
Member

wasade commented Oct 23, 2020

Thanks, @AmandaBirmingham! I think you're spot on with the bullet points. The first two cases are "easy" going from not is_microsetta to is_microsetta. The second bullet point probably just needs to exercise the if-statement here, which would probably be easiest if that block was decomposed. The harder item, as you note, is from is_microsetta to not is_microsetta. I agree that we should not allow that action if any kit has been used.

@@ -84,18 +91,24 @@
// of the relevant cell in the projects table
formElm.val(this.innerText);
}

// some fields can be set only on creating a new project, not modifying an existing one
let is_create_only = $("#" + this.id).hasClass("create_only");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is super clean

@wasade wasade merged commit f821847 into master Oct 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants