• I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.

Hi all,

We run several Joomla sites that are written to through the Web Services API, and found records staying checked out after a PATCH was refused. The next person to open the record in the backend was told it was checked out by the API user. Related, but not the same case: #42219 (that report was about successful updates and could not be reproduced).

Summary of Changes

ApiController::edit() checks the record out and then calls save(). save() throws when the form validation fails (InvalidParameterException) or when the model refuses the save (Exception\Save), and both happen before the check-in at the end of save(). So every refused PATCH left the record checked out to the API user.

edit() now wraps the save() call and checks the record back in before rethrowing. It only does so when this request took the check-out, so a lock the user already held stays in place. This mirrors the HTML forms: FormController keeps the record checked out after a refused save because the user returns to the edit form and later saves or cancels, but an API request has no follow-up edit or cancel, so the refusal ends the edit. A successful save is unchanged (save() still does its own check-in), and FormModel::checkin() already returns early for tables without check-out columns.

Tests:

• Unit: new tests/Unit/Libraries/Cms/MVC/Controller/ApiControllerTest.php covers a refused edit and a successful edit.
• System: new case in tests/System/integration/api/com_content/Articles.cy.js, "does not leave an article checked out when an update is refused", which sends a PATCH with an empty title and checks checked_out afterwards.

Both new tests fail without this change (the Cypress case reports the API user's id as the checked_out value) and pass with it. Run locally with the system-test Docker image: npx cypress run --spec tests/System/integration/install/Installation.cy.js,tests/System/integration/api/com_content/Articles.cy.js.

Testing Instructions

Test on current 6.2-dev.

1. Enable the Web Services plugin for Content and the API Authentication - Token plugin, and create an API token for a Super User.
2. Create an article (any category).
3. Send a PATCH that the form refuses, for example an empty title:
   PATCH /api/index.php/v1/content/articles/{id} with body {"title": ""}
4. The API answers with "Field required: Title". Open Content > Articles in the backend.

Actual result BEFORE applying this Pull Request

The article shows the checked-out lock, held by the API user. Opening it as another user reports that it is checked out, and it stays that way until someone checks it in.

Expected result AFTER applying this Pull Request

The API still answers with "Field required: Title", and the article is not checked out. A valid PATCH (for example {"title": "New title"}) still saves and leaves the article checked in, as before.

Link to documentations

Please select:

• Documentation link for guide.joomla.org:

• No documentation changes for guide.joomla.org needed

• Pull Request link for manual.joomla.org:

• No documentation changes for manual.joomla.org needed

Thanks for taking a look. Happy to change the approach or the test if you'd prefer it done differently.