Multiple allowed users for PermitArea (HPH-36) #276
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add a QuerySet method named "for_user" for PermitAreas and use it instead of direct filtering by the field name. This allows changing the field name without changes to these filters. Refs HPH-36
suutari-ai
force-pushed
the
permit-area-multiple-users
branch
from
51116b0 to
ecb07b5
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #276 +/- ##
==========================================
- Coverage 94.70% 94.48% -0.22%
==========================================
Files 187 190 +3
Lines 5797 5843 +46
Branches 389 398 +9
==========================================
+ Hits 5490 5521 +31
- Misses 240 250 +10
- Partials 67 72 +5 ☔ View full report in Codecov by Sentry. |
Add a new many-2-many field named "allowed_users" to PermitArea and populate it with the user object from the "permitted_user" field. This allows multiple operators/enforcers to use the same PermitAreas for their permits. also make the permitted_user field nullable for now to allow migrations to be reversed. Refs HPH-36
Remove the "permitted_user" field from the PermitArea model and update all code to use the "allowed_users" instead, because the field is now redundant. Refs HPH-36
Rename all occurences of "permitted_user" to "allowed_user" so that code matches the new naming of the field. The tests are still utilizing just a single allowed user per area, but that should be fine for now. Refs HPH-36
Make the "allowed_user" parameter optional, since now it's possible to create the PermitAreas without any allowed users and it could make sense to import new areas without assigning them to any users at import time. Refs HPH-36
Add a few test cases that make sure that the creation of permits via the Operator API works correctly even when the PermitArea has more than one allowed user. Refs HPH-36
suutari-ai
force-pushed
the
permit-area-multiple-users
branch
from
ecb07b5 to
7531956
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add support for allowing sharing of the PermitAreas between operators and the enforcer.
Previously it was possible to use each PermitArea for just a single enforcer or operator.
This was especially problematic, because the PermitArea codes were unique within
enforcement domains so it was not even possible to create duplicate areas with the
same identifiers.