-
Notifications
You must be signed in to change notification settings - Fork 4
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
Only accept changes from work packages if they pass the filter #5
Comments
I suggest "team" column should never be populated manually - i plan to disable that in all forms, and if for some reason projects are made in a way that user can enter some value (right or wrong), this value should be updated on every sync with the main project. I don't expect my team members to even know which team they belong to or what their team id is. |
So:
So from this definition unwanted changes are impossible. |
Now I see in wp.py:
So scenario A: Team A - Area A and/or Department A Check - if isinstance(wp_value, (str, int, float)) - always UPDATE tables and set filter column to wp_value when syncing back Additional spatial filter would be usefull... Scenario B: Team A - Area A Check - isinstance(wp_value, list) - just discard data that doesn't have correct values or have NULL values. Delete it and don't collect it anywhere. Other checks should be on us who do our projects. I think you should keep it simple. |
Yeah, if there is only single value allowed for a WP, the default behavior could be to automatically set that value (if not set already). Things get a bit more tricky if there are multiple values allowed - discarding such rows would be an option, or possibly setting the filter column to some special value, so that project admin is aware of the fact there are some issues. |
Currently we are accepting all changes from work packages. We should probably test whether inserted/updated rows from a work package would pass the filtering. If not, we would reject such changes. Any rejected changes would need to be stored somewhere in the master Mergin project. There is a risk with rejections that the invalid edits could be unintended (e.g. the "team" column value would be NULL instead of the expected). Another option would be that instead of rejecting such edits, we would modify such insert/update statements to pass the filtering.
The text was updated successfully, but these errors were encountered: