#Usability

Marking as needs review for an initial review and a few questions on the MR.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

I have implemented the following endpoints as per #16:

1. /canvas/api/v0/usage/{canvas_config_entity_type_id}/{canvas_config_entity} API, which provides a simple boolean true/false response
2. /canvas/api/v0/usage/{canvas_config_entity_type_id}/{canvas_config_entity}/details API, which provides detailed of information that \Drupal\canvas\Audit\ComponentAudit can
3. /canvas/api/v0/usage/{canvas_config_entity_type_id}?page=N which allows iterating over all is paginated-per-50 and lists an object like {id1: true, id2: false, …, id50: true}

I've updated the access check in VisibleWhenDisabledCanvasConfigEntityAccessControlHandler rather than in CanvasConfigEntityAccessControlHandler which may not be correct, but we'd have to inject component audit into the other handlers that extend this which I'm not sure makes sense as its quite specific at the moment.

The above update in the access check resolves the scenario where you have a Code component added to your library that is in use on a canvas page for example and attempt to delete it, previously this would delete the code component.

I've tested #7 and this scenario looks to have been accounted for before this MR.

I'd say this ticket is ready to have a review. Please let me know if I'm wrong with the fix for the tests.

Cheers

Not every stable blocker needs to block an RC, but this one does.

This is actually the first time we’ll be sending email from new.drupal.org, and this has reminded us that we hadn’t set up outgoing email yet. That infrastructure setup is in progress.

As a meta wanted to bump 1 more time before closing.

This is now merged and it will be deployed shortly.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

The subject and body were taken from the D7 version and changed slightly. Ready for review.

Lots of users here so I just credited everyone.

Thanks!

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Added a @todo in here: https://git.drupalcode.org/project/contribution_records/-/blob/1.0.x/src...

Re-rolled the MR,
Please review!!

working on it

I just tested it and can verify that you now have to enter a leading slash as mentioned in #91 as minimal verification. (on Drupal 10.4.5).

.. and as nobody has been complaining about this issue for years. I think this can be closed?