[4.x]: Issue with Element::EVENT_AUTHORIZE_DELETE ?

[ryssbowh]

What happened?

Description

I don't quite understand how the event Element::EVENT_AUTHORIZE_DELETE is supposed to function :

I'm trying to prevent elements deletions in a custom plugin (when the element is referenced in another element).
I remember in Craft 3 we could disable the delete button (on a index element page) by responding to Element::EVENT_DEFINE_IS_DELETABLE, this doesn't seem to be working the same way in Craft 4.

For entries for example, the event's attribute authorized is only considered in Entry::canDelete if it's true. If it's false the system defaults to the permissions deleteEntries:{uid}, and by default its value is false, so responding to this event and setting it to false doesn't do anything.
This seems to be the same for categories, users and assets.

Shouldn't the system have a default value for authorized to null and consider both true and false when checking it in each elements canDelete methods ?

I can prevent deletions using the event Element::EVENT_BEFORE_DELETE and it does work. But the delete button is always active and working, so you get a success message when deleting, but the elements aren't deleted.

Steps to reproduce

1. Respond to the event Element::EVENT_AUTHORIZE_DELETE and set its authorized attribute to false

Expected behavior

The button Delete on an element index page should be disabled ?

Actual behavior

The Delete button on an element index page is still active.

Craft CMS version

4.2.1

PHP version

8.1.2

Operating system and version

Linux Mint 20.2

Database type and version

Mysql 5.7

Image driver and version

No response

Installed plugins and versions

[brandonkelly]

Moved this to a discussion because it’s currently working as intended.

The event is only called if something in the element type hasn’t already authorized it. There’s not currently any way to override the existing authorization if granted.

It wouldn’t be possible to have the event take precedence without adding complexity to each of the elements’ authorization methods, which I wanted to avoid.

We could possibly introduce new authorization service methods that are the source of truth, and fire their own events that take precedence over the element’s authorization methods. Not sure how I feel about that though.

[brandonkelly]

This is resolved for Craft 4.3. All internal element authorization checks have been updated to call new methods in the Elements service, which support preventing authorization when AuthorizationCheckEvent::$authorized is set to false.

See details in the PR (#11808).

[brandonkelly]

Craft 4.3 was released earlier this week with this change!