This is for what @Dostonbek1 and @vidyanambiar and I have been working on.
The UI is planning to carry-forward a practice used in AWX, which is to hide/disable thing based on data from OPTIONS. If a user has permissions to edit an object, PUT/PATCH will be shown, but if the user lacks those permissions, OPTIONS will not show those methods. Thus, if the actions are not present, the UI may disable editing certain things.
The problem with eda-server is that OPTIONS never returned any actions for detail views. This is self-apparent if you understand the intent of PartialUpdateOnlyModelMixin which means PATCH by "PartialUpdate". In other words, a full update (which is PUT) is excluded, and gives 405, method-not-allowed.
This partial-update-only behavior of EDA-server conflicts with DRF logic considers PUT but not PATCH for OPTIONS.
AWX customized the metadata class in a similar way to what is proposed here, adding the GET method:
So for QE, @dhaustein, this is expected to show a change in OPTIONS response so that PATCH is shown in "actions" in the response data. Then the UI will use this, combined with other updates, to determine permissions in advance of actually making an edit.
This is for what @Dostonbek1 and @vidyanambiar and I have been working on.
The UI is planning to carry-forward a practice used in AWX, which is to hide/disable thing based on data from OPTIONS. If a user has permissions to edit an object, PUT/PATCH will be shown, but if the user lacks those permissions, OPTIONS will not show those methods. Thus, if the actions are not present, the UI may disable editing certain things.
The problem with eda-server is that OPTIONS never returned any actions for detail views. This is self-apparent if you understand the intent of
PartialUpdateOnlyModelMixin
which means PATCH by "PartialUpdate". In other words, a full update (which is PUT) is excluded, and gives 405, method-not-allowed.This partial-update-only behavior of EDA-server conflicts with DRF logic considers PUT but not PATCH for OPTIONS.
AWX customized the metadata class in a similar way to what is proposed here, adding the GET method:
https://github.com/ansible/awx/blob/20f054d600689c8c016bce83f8445f3c9b5cffb3/awx/api/metadata.py#L192
So for QE, @dhaustein, this is expected to show a change in OPTIONS response so that PATCH is shown in "actions" in the response data. Then the UI will use this, combined with other updates, to determine permissions in advance of actually making an edit.