Overview

In administrator views such as the Articles view, if a record is checked out by a user then a little padlock symbol is displayed against it. The padlock symbol has a link (to checkin the record) behind it which is enabled if the user has permission to check the record in, or disabled and greyed out if not.

The code in the various core component layout files which determines whether to enable the link is based on if the user is the same as the one who checked out the record, or if the user has core.manage permission on com_checkin.

However the code in FormModel::checkin() which performs the checkin actually checks if the user is the same as the one who checked out the record, or if the user has core.admin permission on com_checkin.

Steps to reproduce the issue

1. Create a manager user within a user group like the manager user group of the Joomla sample install data. Ensure that the manager usergroup permissions for Checkin (com_checkin) are
   Configure ACL & Options: Not Allowed
   Access Administration Interface: Allowed

2. With a user other than the manager user, checkout an article (eg by editing it).

3. Log in elsewhere as the manager user, and display the Articles. A padlock symbol should appear against the checked out record, with a link enabled behind it.

4. Click on the padlock symbol. Joomla will return with an error
   Check-in failed with the following error: The user checking in does not match the user who checked out the item.

Expected result

The record should be checked in

Actual result

The checkin attempt is rejected with an error message.

System information (as much as possible)

Joomla 3.8

Additional comments

The manager user can checkin the record using the System / Global Check-in feature, because this functionality checks that the user has the core.manage permission for com_checkin (in administrator/components/com_checkin/checkin.php) and doesn't use the FormModel::checkin() code to perform the checkin.

As far as I can determine, the FormModel::checkin() functionality used to work correctly, but was changed to check against core.admin in #25540. I think this change should be reversed.