Having all check methods in the authorizer is no doubt a case of the blob antipattern (See http://en.wikipedia.org/wiki/God_object) . Issue #39 will introduce at least 13 more check methods which will amplify this. I believe we can improve maintainability of the authorizer by separating the check methods into multiple files based on functionality.
I have compiled a list of all check methods and which roles use them. There are only 7 check methods used by more than 1 role.
I propose a breakdown into the following suites:
Note: (...) indicates which role(s) are currently using the method.
refund_does_not_exceed_payment (Admin),
purchase_order_has_no_payments (Owner of purchase order with no payments),
purchase_order_has_payments (Owner of purchase order with payments),
pr_services.authorizer.checks.product_line
actor_is_product_line_manager_of_session_template (Product Line Manager),
actor_is_product_line_manager_of_user (Product Line Manager),
actor_is_product_line_manager_of_product_line (Product Line Manager),
actor_is_product_line_manager_of_session (Product Line Manager),
It would also be necessary to qualify which suite the methods are in when defining roles. The import machinery in the authorizer would be trivial to implement this way.
Having all check methods in the authorizer is no doubt a case of the blob antipattern (See http://en.wikipedia.org/wiki/God_object) . Issue #39 will introduce at least 13 more check methods which will amplify this. I believe we can improve maintainability of the authorizer by separating the check methods into multiple files based on functionality.
I have compiled a list of all check methods and which roles use them. There are only 7 check methods used by more than 1 role.
I propose a breakdown into the following suites:
Note: (...) indicates which role(s) are currently using the method.
pr_services.authorizer.checks.auth
pr_services.authorizer.checks.membership
pr_services.authorizer.checks.membership.orgadmin
pr_services.authorizer.checks.ownership
pr_services.authorizer.checks.constraint
pr_services.authorizer.checks.assignment
pr_services.authorizer.checks.payment
pr_services.authorizer.checks.product_line
It would also be necessary to qualify which suite the methods are in when defining roles. The import machinery in the authorizer would be trivial to implement this way.
ie.