feat: project change intervals on preset change #1063
Conversation
Ran into a bug on the frontend when I tried creating a new project. This commit makes sure that the project has a soil project settings associated it. It also allows this to be disabled if we're creating a project from somewhere where the project soil settings is not necessary.
…ject-change-intervals-on-preset-change
| with transaction.atomic(): | ||
| result = super().save(*args, **kwargs) | ||
| if "depth_interval_preset" in dirty_fields or not self.id: | ||
| # delete project intervals... |
There was a problem hiding this comment.
| # delete project intervals... | |
| # delete project intervals |
There was a problem hiding this comment.
comment: my thinking when designing the backend data format for this was that the preset data would be stored on the client rather than updated in the backend. so the actual project depth interval rows would only represent the depth intervals for a custom depth interval selection, and when a preset is selected the client just ignores those values. this was intended to be a low implementation/UX complexity safeguard against accidental data deletion (since otherwise the only thing preventing someone from deleting all their project data by changing the preset is a confirmation dialog that can easily be mis-clicked). this definitely makes the API more consistent which is nice, but i'm not sure we should go ahead with it until we can replace that safeguard
|
Superseded by #1081, closing |
Description
Checklist
Related Issues
Fixes #....
Verification steps