Problem/Motivation

Issue reported in drupal watchdog logs

TypeError: Drupal\sitewide_alert\Entity\SitewideAlert::getOwner(): Return value must be of type Drupal\user\UserInterface, null returned in Drupal\sitewide_alert\Entity\SitewideAlert->getOwner() (line 174 of /var/www/html/docroot/modules/contrib/sitewide_alert/src/Entity/SitewideAlert.php)

Steps to reproduce

1. Create a sitewide alert
2. edit the created one
e.g.- /admin/content/sitewide_alert/6

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork sitewide_alert-3535750

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

suryabhi created an issue. See original summary.

suryabhi’s picture

suryabhi commented
Issue summary: View changes
suryabhi’s picture

suryabhi commented
Title: getOwner(): Return value must be of type Drupal\user\UserInterface, null returned » TypeError:getOwner(): Return value must be of type Drupal\user\UserInterface, null returned

suryabhi opened merge request !74

suryabhi’s picture

suryabhi commented
Status: Active » Needs review
suryabhi’s picture

suryabhi commented
Issue summary: View changes
shubham_pareek_19’s picture

shubham_pareek_19 commented
Status: Needs review » Needs work

I have tested this issue as per the provided steps:

Created a Sitewide Alert.

Edited the alert via /admin/content/sitewide_alert/{id}.

Also tried deleting the user who created the alert (with “Delete the account and make its content belong to the Anonymous user” option).

However, I was not able to reproduce the TypeError mentioned in the issue summary. The alert edit page loads without any errors, and I do not see any related entries in the Watchdog logs (/admin/reports/dblog).

To ensure I'm not missing something, could you please elaborate on the exact conditions required to trigger the error (e.g., should the owner field be manually unset or reference a missing UID)?

It would also be helpful if you could re-test this on your end and confirm whether it is still reproducible with the current codebase.

Thanks!

suryabhi’s picture

suryabhi commented

1. Create a different role
2. Create a user with that role
3. Give add and edit sitewide alert permission to the user
4. then try access to /admin/content/sitewide_alert/6

Hope you will able to reproduce the error. I am not reproduce the error with user 1 and the have followed the above step

shubham_pareek_19’s picture

shubham_pareek_19 commented

@suryabhi
i have also follow these new steps but still i am uable to reproduce this issue , i have created new role and a new user of that role. Then with that new user I tried to edit the content created by the admin and also tried to edit the sitewide created by that new user with the admin's role. In both the cases I did't get ay error, pls tell me if I am missing somethig here.

Thanks,

malcomio’s picture

malcomio commented

I've been able to reproduce this issue when trying to edit an old alert, which was edited by a user whose account no longer exists.

It doesn't seem to happen for newly created alerts, or alerts where the user still exists.

The merge request does not address the problem, as the return value can still be null.

malcomio’s picture

malcomio commented
Status: Needs work » Needs review

I've pushed a change in the branch that handles this scenario, but I think that the real problem is that the module does not implement hook_user_cancel - see #3537797: Implement hook_user_cancel

smustgrave’s picture

smustgrave commented
Status: Needs review » Needs work

I'm not seeing this but not sure defaulting to anonymous user.

smustgrave’s picture

smustgrave commented
Status: Needs work » Fixed
Related issues: +#3537797: Implement hook_user_cancel

I see this error now and agree we should address in #3537797: Implement hook_user_cancel linking that issue but good fallback

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

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

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.