added python-setuptools to install for rhel fix for issue #12#13
Merged
Conversation
devGregA
pushed a commit
that referenced
this pull request
Mar 25, 2015
added python-setuptools to install for rhel fix for issue #12
dogboat
referenced
this pull request
in dogboat/django-DefectDojo
Apr 29, 2024
Merge Master back into Dev
Maffooch
pushed a commit
to devGregA/django-DefectDojo
that referenced
this pull request
Apr 30, 2026
…apper Add a string Action enum that names the legacy permission vocabulary (view / edit / add / delete / import / staff_only / superuser_only) and a suffix-driven permission_to_action() helper that flattens any of the existing Permissions enum members down to one of those actions. The fine-grained Permissions enum is preserved so existing call sites (`@user_is_authorized(Permissions.X, ...)`) keep compiling. Track B step DefectDojo#13 will simplify the call sites to action strings; until then this gives authorization.py a single dispatch surface that accepts both the legacy Permissions enum members AND the new action strings. Roles enum preserved purely as a label set — legacy authorization no longer branches on roles. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Maffooch
pushed a commit
to devGregA/django-DefectDojo
that referenced
this pull request
Apr 30, 2026
… model
Replace the hierarchical RBAC role lookups in user_has_permission /
user_has_global_permission with the pre-2020 authorization model:
* superuser -> always allowed
* StaffOnly / Delete actions -> require is_staff
* SuperuserOnly -> require is_superuser (already handled above)
* View / Edit / Add / Import -> climb the
Product_Type <- Product <- Engagement <- Test <- Finding
chain looking for membership in obj.authorized_users; staff users
bypass for non-View actions.
Object-shape carriers (Risk_Acceptance, Endpoint, Cred_Mapping,
Product_Member, Group, etc.) delegate to their wrapped product /
product_type, except for self-deletion of one's own membership row,
which any user is allowed to do.
Configuration permissions (user.has_perm("dojo.X")) preserved as-is —
they're already a Django auth-perm pass-through that doesn't depend on
RBAC.
Public surface preserved:
user_has_permission(user, obj, permission)
user_has_global_permission(user, permission)
user_has_configuration_permission(user, codename)
user_*_or_403(...) wrappers
user_is_superuser_or_global_owner(user) -> now just is_superuser
get_roles_for_permission / role_has_permission / role_has_global_permission
-> empty / False stubs
get_product_member / get_groups / etc. -> None / empty stubs
The stubs let the 117 transitional call sites compile while Track B
step DefectDojo#13 simplifies them. Pro deployments that need real RBAC continue
to use pro.authorization.services, which Pro's apps.ready() shadows
into this module at startup.
Verified: superuser/anon/staff branches return correct values against
bare_bones fixture data.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Maffooch
pushed a commit
to devGregA/django-DefectDojo
that referenced
this pull request
Apr 30, 2026
…alse shells Migration 0268_release_rbac_state.py flips the seven RBAC models in dojo's app state to ``managed=False`` via AlterModelOptions. Pairs with ``pro.0049_adopt_rbac_tables`` (Pro creates the same models in its state via SeparateDatabaseAndState with state_operations only). Together the two migrations transfer schema ownership from dojo to pro without running any DDL — the underlying tables are bit-for-bit unchanged, every existing row stays in place, and constraints / indexes are not touched. The model class definitions remain in dojo/authorization/models.py as managed=False shells with related_name="+" on every FK to a dojo-owned model (suppresses reverse-accessor name clashes against Pro's now-managed copies). Track B step DefectDojo#13 simplifies the OS callers that still isinstance-check or import these classes; at that point the shells are deleted entirely and OS-only deployments stop carrying their dead weight. Verified end-to-end: - ``migrate`` applies pro.0049 → dojo.0268 in correct cross-app order (run_before on the pro migration enforces it). - ``select count(*) from dojo_role/dojo_global_role/dojo_product_member`` unchanged after migration; no rows moved or rebuilt. - Pro queries ``Role.objects.count()`` returns the same row counts via the new pro app state. - Reverse accessor ``product.product_member_set.all()`` resolves to Pro's Product_Member instances (the canonical owner now). - 442 tests across pro/authorization, pro/api/authorization, api_helpers, and dashboard/test_views_extended remain green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Maffooch
pushed a commit
to devGregA/django-DefectDojo
that referenced
this pull request
Apr 30, 2026
Bulk-replace 205 permission filter argument strings across 28 templates in dojo/templates/. Same suffix-based mapping used in DefectDojo#13 for the Python call sites: "Product_View"|has_global_permission -> "view"|has_global_permission has_object_permission:"Finding_Edit" -> has_object_permission:"edit" has_object_permission:"Risk_Acceptance" -> has_object_permission:"edit" has_object_permission:"Import_Scan_Result" -> has_object_permission:"import" has_object_permission:"X_Manage_Members" -> has_object_permission:"staff_only" ... Updated dojo/authorization/template_filters.py to pass the permission string straight through to user_has_*_permission() instead of going via ``Permissions[name]``. ``permission_to_action()`` already handles the new action strings; this commit also extends it to fall back through the suffix mapping when given a legacy enum-name string, so the transition window where some templates use the old form and others the new is safe. Verified: Pro authorization smoke tests + templatetag bridge intact; authorization_tags filters still resolve to Pro implementations under Pro deployment. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Maffooch
pushed a commit
to devGregA/django-DefectDojo
that referenced
this pull request
May 8, 2026
…apper Add a string Action enum that names the legacy permission vocabulary (view / edit / add / delete / import / staff_only / superuser_only) and a suffix-driven permission_to_action() helper that flattens any of the existing Permissions enum members down to one of those actions. The fine-grained Permissions enum is preserved so existing call sites (`@user_is_authorized(Permissions.X, ...)`) keep compiling. Track B step DefectDojo#13 will simplify the call sites to action strings; until then this gives authorization.py a single dispatch surface that accepts both the legacy Permissions enum members AND the new action strings. Roles enum preserved purely as a label set — legacy authorization no longer branches on roles. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Maffooch
pushed a commit
to devGregA/django-DefectDojo
that referenced
this pull request
May 8, 2026
… model
Replace the hierarchical RBAC role lookups in user_has_permission /
user_has_global_permission with the pre-2020 authorization model:
* superuser -> always allowed
* StaffOnly / Delete actions -> require is_staff
* SuperuserOnly -> require is_superuser (already handled above)
* View / Edit / Add / Import -> climb the
Product_Type <- Product <- Engagement <- Test <- Finding
chain looking for membership in obj.authorized_users; staff users
bypass for non-View actions.
Object-shape carriers (Risk_Acceptance, Endpoint, Cred_Mapping,
Product_Member, Group, etc.) delegate to their wrapped product /
product_type, except for self-deletion of one's own membership row,
which any user is allowed to do.
Configuration permissions (user.has_perm("dojo.X")) preserved as-is —
they're already a Django auth-perm pass-through that doesn't depend on
RBAC.
Public surface preserved:
user_has_permission(user, obj, permission)
user_has_global_permission(user, permission)
user_has_configuration_permission(user, codename)
user_*_or_403(...) wrappers
user_is_superuser_or_global_owner(user) -> now just is_superuser
get_roles_for_permission / role_has_permission / role_has_global_permission
-> empty / False stubs
get_product_member / get_groups / etc. -> None / empty stubs
The stubs let the 117 transitional call sites compile while Track B
step DefectDojo#13 simplifies them. Pro deployments that need real RBAC continue
to use pro.authorization.services, which Pro's apps.ready() shadows
into this module at startup.
Verified: superuser/anon/staff branches return correct values against
bare_bones fixture data.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Maffooch
pushed a commit
to devGregA/django-DefectDojo
that referenced
this pull request
May 8, 2026
…alse shells Migration 0268_release_rbac_state.py flips the seven RBAC models in dojo's app state to ``managed=False`` via AlterModelOptions. Pairs with ``pro.0049_adopt_rbac_tables`` (Pro creates the same models in its state via SeparateDatabaseAndState with state_operations only). Together the two migrations transfer schema ownership from dojo to pro without running any DDL — the underlying tables are bit-for-bit unchanged, every existing row stays in place, and constraints / indexes are not touched. The model class definitions remain in dojo/authorization/models.py as managed=False shells with related_name="+" on every FK to a dojo-owned model (suppresses reverse-accessor name clashes against Pro's now-managed copies). Track B step DefectDojo#13 simplifies the OS callers that still isinstance-check or import these classes; at that point the shells are deleted entirely and OS-only deployments stop carrying their dead weight. Verified end-to-end: - ``migrate`` applies pro.0049 → dojo.0268 in correct cross-app order (run_before on the pro migration enforces it). - ``select count(*) from dojo_role/dojo_global_role/dojo_product_member`` unchanged after migration; no rows moved or rebuilt. - Pro queries ``Role.objects.count()`` returns the same row counts via the new pro app state. - Reverse accessor ``product.product_member_set.all()`` resolves to Pro's Product_Member instances (the canonical owner now). - 442 tests across pro/authorization, pro/api/authorization, api_helpers, and dashboard/test_views_extended remain green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Maffooch
pushed a commit
to devGregA/django-DefectDojo
that referenced
this pull request
May 8, 2026
Bulk-replace 205 permission filter argument strings across 28 templates in dojo/templates/. Same suffix-based mapping used in DefectDojo#13 for the Python call sites: "Product_View"|has_global_permission -> "view"|has_global_permission has_object_permission:"Finding_Edit" -> has_object_permission:"edit" has_object_permission:"Risk_Acceptance" -> has_object_permission:"edit" has_object_permission:"Import_Scan_Result" -> has_object_permission:"import" has_object_permission:"X_Manage_Members" -> has_object_permission:"staff_only" ... Updated dojo/authorization/template_filters.py to pass the permission string straight through to user_has_*_permission() instead of going via ``Permissions[name]``. ``permission_to_action()`` already handles the new action strings; this commit also extends it to fall back through the suffix mapping when given a legacy enum-name string, so the transition window where some templates use the old form and others the new is safe. Verified: Pro authorization smoke tests + templatetag bridge intact; authorization_tags filters still resolve to Pro implementations under Pro deployment. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
No description provided.