potiuk commented on code in PR #70243:
URL: https://github.com/apache/airflow/pull/70243#discussion_r4064703442
##########
providers/fab/tests/unit/fab/www/views/test_views_custom_user_views.py:
##########
@@ -141,6 +141,49 @@ def test_user_model_view_with_access(self, url,
permission, expected_text, app,
response = client.get(url.replace("{user.id}",
str(user_with_access.id)), follow_redirects=True)
check_content_in_response(expected_text, response)
+ def test_user_edit_view_shows_reset_password_action_with_access(self, app,
client):
+ # Visibility of the action link is gated on "read" access to Users
(the same
+ # rule the Show User view relies on); "read" on Passwords is what's
required to
+ # actually perform the reset once the link is followed.
+ user_with_access = create_user(
+ app,
+ username="has_access",
+ role_name="role_has_access",
+ permissions=[
+ (permissions.ACTION_CAN_READ, permissions.RESOURCE_WEBSITE),
+ (permissions.ACTION_CAN_READ, permissions.RESOURCE_USER),
+ (permissions.ACTION_CAN_EDIT, permissions.RESOURCE_USER),
+ (permissions.ACTION_CAN_READ, permissions.RESOURCE_PASSWORD),
Review Comment:
These two tests vary two permissions at once: the positive case has
`CAN_READ` on both **Users** and **Passwords**, the negative has neither. So
the pair is equally consistent with "gated on Users read" and "gated on
Passwords read" — it can't actually pin the distinction your comment on line
145 draws.
For what it's worth, I traced it and **your comment is correct**:
`render_action_links` → `get_actions_on_show` →
`is_item_visible("resetpasswords", …)`, which resolves
`get_action_permission_name("resetpasswords")` through `method_permission_name`
to `can_read`, and checks it against `class_permission_name`. On the edit
endpoint that property (`user.py:61-70`) falls through
`class_permission_name_mapping` to `RESOURCE_USER`; only on the `action`
endpoint does it map to `RESOURCE_PASSWORD`. So visibility really is Users-read
and execution really is Passwords-read.
The case that would pin it is the one that's missing — `CAN_READ` on Users
*without* `CAN_READ` on Passwords. The link renders and the action 403s. That's
pre-existing behaviour you've inherited from the Show view rather than anything
you've introduced, but on an auth surface it's the seam most worth having a
test say out loud.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
