CFM-496_REST_API_v2_DELETE_CO_Group_returns_400 #360
Conversation
| // Align with REST API: do not allow delete of read-only records | ||
| if (method_exists($obj, "isReadOnly") && $obj->isReadOnly()) { | ||
| $this->Flash->error(__d('error', 'edit.readonly')); | ||
| // Redirect to view, as we do for read-only edits | ||
| return $this->redirect(['action' => 'view', $obj->id]); | ||
| } | ||
|
|
There was a problem hiding this comment.
How does one trigger the delete of a read only record? The UI shouldn't offer that option in the first place.
There was a problem hiding this comment.
@benno Previously the delete logic ran before we checked isReadOnly, so a crafted DELETE or POST could actually delete a read‑only record even though the API then returned an error.
The UI already hides the delete button for read‑only entities, so normal users could not trigger this through the interface.
The issue only appeared when someone called the delete endpoint directly. The change moves the read‑only check ahead of the delete call, so those crafted requests are rejected before any data is removed.
In short, the UI blocks delete for read‑only records, and this change closes the remaining gap for manually crafted delete requests.
… users. Fix api user key title caclulation bug.
Ioannis
force-pushed
the
CFM-496_REST_API_v2_DELETE_CO_Group_returns_400
branch
from
0f9899d to
386d9de
Compare
…strict detail to platform API users
|
@benno I’ve updated the PR based on your feedback; please continue the review when convenient. Thanks. |
Uh oh!
There was an error while loading. Please reload this page.