Pull Request resolves #48253 .

• 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.

Summary of Changes

In the admin, several fields let you pick an item through a modal and then edit it in place (article, contact, news feed, category, menu item). Until now these offered an Edit button even when the referenced item was checked out by somebody else.
This patch makes the core field (ModalSelectField) detect that and hide the Edit button, with a note explaining why.

As a second line of defence the field no longer sends a check-in at all for an item it knows to be checked out by someone else, the dialog could not have checked it out, so closing it must not release another user's lock. That covers the cases where the button is reached anyway, for example a select dialog which does not report the state or an item locked between rendering and clicking.

As a user without Global Check-in permission the lock survives either way, but before the patch they were still offered an Edit button.

TBD Backport PR to 5.4-dev

Follow up fixes for https://github.com/joomla/joomla-cms/pull/48300/changes#r3849309890

Testing Instructions

Prerequisites

• A Joomla test site with at least two Super User accounts (say admin and tester), or one
  account plus a private/incognito window.
• At least one article, e.g. "Test Article".

Setup - lock an article as another user

1. Log in as tester in a second browser (or a private window).
2. Go to Content → Articles, click Test Article to open it for editing.
3. Leave the tab open — the article is now checked out by tester. Do not press Save & Close.

Verify in Content → Articles that the article now shows the padlock icon.

Test 1 - Edit button is hidden for an item locked by someone else

1. As admin, go to Menus → Site → Add New Menu Item.
2. Menu Item Type → Articles → Single Article.
3. In the Select Article field, click Select and choose Test Article.
4. Save & Close, then reopen the menu item (the field must have a stored value).

• Before the patch: the Edit button is shown next to the article title.
• After the patch: the Edit button is gone, and below the field you see:
  "Editing is disabled because the item is checked out by another user."
  The Select and Clear buttons still work as before.

Test 2 - your own lock does not block you

1. As admin, open Test Article in Content → Articles, then leave via the browser's Back
   button (this leaves it checked out by you).
2. Open the menu item from Test 1 again (make sure it points at that article).

Expected, before and after the patch: the Edit button is shown and works. Only other
users' locks disable it.

Test 3 - selecting a checked-out item hides the Edit button straight away

1. Open the menu item from Test 1 and click Clear, or start a new one.
2. Click Select. In the list, Test Article now carries a padlock icon, the same one the article
   manager shows; it reads out as "Checked out" plus who holds it and since when. Before the patch
   the select list gave no clue at all. Checked-out items stay selectable — only editing is blocked.
3. Pick Test Article.
4. Do not reload the page.

• Before the patch: the Edit button appears as soon as the article is selected. Clicking it
  opens the article with a "checked out by another user" error, and closing the dialog releases
  tester's lock if you hold Global Check-in permission (see Test 4).
• After the patch: the Edit button stays hidden and the note appears immediately, without a
  page reload.

5. Now click Select again and pick an article that is not checked out. The Edit button must
   come back and the note must disappear - again without reloading.

Test 4 - another user's lock is no longer released behind their back

With Test Article checked out by tester, as admin (a Super User):

• Before the patch: open the menu item, click Edit. The article opens with an error and
  cannot really be edited. Close the dialog and look at Content → Articles — the padlock is
  gone: tester's lock was released without them noticing, and their next Save & Close fails.
• After the patch: there is no Edit button, so no check-in is sent and the lock survives.
  tester can still Save & Close normally.

Test 5 — an item created or edited through the field is checked in again

1. Open a menu item with an article field whose value is empty and click New.
2. Fill in a title, press Save (not Save & Close), then close the dialog with the X.
3. Go to Content → Articles and look for the new article.

• Before the patch: the new article carries a padlock — it stays checked out to you.
• After the patch: no padlock, the article is checked in.
  The dialog's Save button (apply) checks the item out again, so closing the dialog has to release it. This was only handled for the Edit button.

4. Repeat with the Edit button on an existing article (Save, then close with the X). It must be
   checked in in both cases.

Test 6 - no Save button in the dialog for a checked-out item

The dialog edit view can still be reached directly (by URL, or from a select list which does not report the check-out state), and until now it offered Save and Save & Close there. Nothing on the save path stops the write, so pressing Save overwrote the other user's work.

1. With Test Article checked out by tester, open as admin:
   /administrator/index.php?option=com_content&view=article&layout=modal&tmpl=component&task=article.edit&id=<articleId>
2. Look at the toolbar of that dialog view.

• Before the patch: Save and Save & Close are offered. Saving overwrites tester's article.
• After the patch: only Cancel is offered, matching what the normal (non-modal) edit view has
  always done.

3. Repeat for a contact, a news feed, a category, a module and a plugin (view=contact,
   view=newsfeed, view=category&extension=com_content, view=module, view=plugin). The menu
   item view already behaved correctly and must keep doing so.
4. With an article that is not checked out, or checked out to you, Save and Save & Close must
   still be there.

Test 7 - no regression in normal use

Check the article back in first (System → Global Check-in, or Save & Close as tester), then with an article that is not checked out:

1. Select - the modal opens, picking an article fills the title into the field.
2. New - creating an article from the modal works and gets selected.
3. Edit - opens the article, Save & Close returns to the form, and the article is not left
   checked out afterwards (check Content → Articles: no padlock). This confirms the automatic
   check-in still works.
4. Clear - empties the field.
5. The selected item's title is shown in the read-only input, not its numeric id. Check this for
   the contact and news feed fields in particular: those tables store the title in a name column,
   so a wrong column would show the raw id plus a database error message.
6. Edge case for the refactored title query: point the field at a deleted article (delete the
   article from the trash, then reopen the form). The field should fall back to showing the raw id
   and must not throw an error.

Fields covered

The modal field never lives on the item's own edit form. In every case below you open another
item (a menu item, a user note, a plugin) which references the checked-out item through a modal
field - you never open the checked-out item itself.

For each row: select the item in the field, save and reopen the form, then check the item out as a
second user and reload the form. Expected after the patch: the Edit button is gone and the note
"Editing is disabled because the item is checked out by another user." is shown. Before the patch
the Edit button is still there.

To be aware of while testing:

• Do not use the article field in the Articles module (Module → Articles → "Select Article").
  That field is configured with edit="false", so it never shows an Edit button — it would look like
  a pass even without the patch.

Actual result BEFORE applying this Pull Request

Checked out items are editable by another user via the field modal. Check-out is not respected.

Expected result AFTER applying this Pull Request

Checked out items are not editable by another user and all fields work as expected.

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