[5.2] Delete user access level - check for levels in use

[chmst]

Pull Request replacing https://github.com/joomla/joomla-cms/pull/39654

Summary of Changes

An access level can only be deleted if there is no content which uses this level. But there is no information given, which tabels are concerned. This PR adds the list of tables to the error message. It adds the delete method to the model and makes a check for all leves on all tables.

Testing Instructions

Add one or more access levels.
Set this access level for some items in your content, an article, a contact, a module .. whatever. Then try to delete this access level.

Actual result BEFORE applying this Pull Request

You get a message "You can't delete the view access level '%d:%s' because it is being used by content."

Expected result AFTER applying this Pull Request

Information is diplayed for all levels, where they are used. This enables the experienced user to find the components and filter there for these levels.

Only leves are deleted (in my test above it was one (1) which are not in use.

Link to documentations

Please select:

• [ ] Documentation link for docs.joomla.org:

• [x] No documentation changes for docs.joomla.org needed

• [ ] Pull Request link for manual.joomla.org:

• [x] No documentation changes for manual.joomla.org needed

[exlemor]

I have tested this item :white_check_mark: successfully on e449b223be9ba5b5d6e385d1c481d7e12c066172

I was able to test this successfully.

Just one tiny correction, the message after Patch is correct unlike the photo:

(photo) View Access Levels removed ---> (site) No View Access Levels removed.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43223.}

[chmst]

In this case I wanted to delete 3 levels. One of them was deleted. Two of them could not be deleted, they are still in use. This is a bit confusing on the screen

[exlemor]

Ah ok. In my case, I tried to delete just 1 level.

[cybersalt]

I have tested this item :white_check_mark: successfully on 615eb4e8d8c67d3b21c0260bf52ab5610abe49b0

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43223.} I created 3 access levels, assigned 3 different articles (one to each) and then tried deleting the 3 levels. The message was the same for all three levels.

[exlemor]

I have tested this item :white_check_mark: successfully on 615eb4e8d8c67d3b21c0260bf52ab5610abe49b0

I have successfully tested it with 2 levels and multiple assets connected to said user levels.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43223.}

[johnaspr]

I have tested this item :white_check_mark: successfully on 615eb4e8d8c67d3b21c0260bf52ab5610abe49b0

I was able to test this. Message after applying the patch: "You can't delete the view access level(s) Level with ID 8 is being used in the database tables: ifsam_content, ifsam_finder_links."

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43223.}

[alikon]

rtc

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43223.}

[HLeithner]

This pull request has been automatically rebased to 5.2-dev.

[joomdonation]

Sorry, I see few problems with this PR :

• It assumes that we always use access field to store access level for the item. In real life (for example, in one of the table in my extension, I uses registration_access field to store the access level which can register for the event, and the check is ignored for this field (unfortunately, I don't see any reliable way to handle this)
• What if access field in certain table is used for different purpose, I mean not for storing access level? By quick code reading, look like this will prevent the access level from being deleted ?
• The code in the model is building the HTML message and return feedback to users via Factory::getApplication()->enqueueMessage and I think this is not a right way. Ideally, the model method should only do the task and return the result to the controller and then it's up to the controller to decide how to return / display that result to users.

[chmst]

@Quy I don't see the remarks as "update requested". @joomdonation I agree with you. But - I think that your remarks are not in scope of this PR. Because there were conceptual errors in the whole ACL and I cannot heal that in a PR. We have the same problem also in other components. They all stop processing when the first problem occours.

You could see this as a work-around. I have no problems with closing the PR but surely cannot re-build this handling of the core components.

[chmst]

Changed the code for displaying the message as requested.

[pe7er]

Thanks for this PR @chmst This PR has been changed, @cybersalt @exlemor @johnaspr Could you please test again?

[dorisdreher]

I have tested this item :white_check_mark: successfully on f8ee84c6d52d541eeae36667db760a8fa86e02f9

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43223.}

[KingLouis1]

I have tested this item :white_check_mark: successfully on f8ee84c6d52d541eeae36667db760a8fa86e02f9

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43223.}

[crimle]

I have tested this item :white_check_mark: successfully on f8ee84c6d52d541eeae36667db760a8fa86e02f9

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43223.}

[MacJoom]

I have tested this item :white_check_mark: successfully on f8ee84c6d52d541eeae36667db760a8fa86e02f9

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43223.}

[pe7er]

Thanks @chmst !