Automated Process User: The new owner must have read permission

[mspiep01]

Occassionally I receive unhandled error exception emails from Logger - Error Notification stating that:

Logger failed to save 1 Log__c records for autoproc@redacted (User ID: redacted)

Error Messages:

The new owner must have read permission

I'm a bit stumped on this one as the notification doesn't provide much guidance.

Do I have a misconfig here?

[jongpie]

Hi @mspiep01 - I haven't encountered this error before, so I'm also stumped on this one. Based on the error, I think it's either an issue with the logging user (the user that generated the logging data), or the autoproc user. My guess is it's related to the logging user.

Some related context: by default, new Log__c records are created by the autoproc user, and assigned to the logging user (using the field Log__c.OwnerId). This functionality has been around for a long time & hasn't previously caused problems that I'm aware of, but there very well could be an overlooked edge case with your org's data.

A couple o' questions about your org:

• Have any permissions (or other settings) been customized for the autoproc user in the org?
• Does this error happen only for certain user(s)?
  • If so does it always happen for those users?
  • If it does always happen for those users, does the error stop if you assign the permission set LoggerLogViewer to the logging user?

[mspiep01]

No worries, still experiencing the issue. Trying to tweak security to see if I can narrow it down.

[jongpie]

@mspiep01 good news, I was finally able to reproduce the issue! 🥳 There appear to be certain users that cannot own records in custom objects, resulting in the error you've been having. It can happen with the autoproc user, as well as several user license types.

To reproduce the issue, I went into one of my scratch orgs, and found/created users that did not have the 'Salesforce' license type, using the query SELECT Id, Name, Username, ProfileId, Profile.name, Profile.UserLicense.Name FROM User ORDER BY Name - results are shown below, with the last column (in red) being the key field to look at.

If I try to manually update a Log__c record to set OwnerId to a user with the license type 'Salesforce', everything works fine. But if I use a user with one of the other license types (like the autoproc user, a Chatter Free user, or an Identity user), I get the same error you've been having:

I'll treat this as a bug - Nebula Logger should (somehow) know to not assign certain Log__c records to the logging user, if the logging user does not have a fitting license type. Given that there are also problems assigning records to the autoproc user (the running user that generates the Log__c records), I'll have to figure out how to determine (or configure?) a default/fallback user. Another possible solution is that I include a queue that has access to the Log__c object, and I could then assign any problematic records to that queue, but I'll have to tinker with it to see what seems best (let me know if you have thoughts!).

For now, I think you can work around the issue by updating the field LoggerSettings__c.DefaultLogOwner__c (shown in the screenshot below) to be either a queue, or a user that does have the 'Salesforce' license type. Let me know if this works in your org!

[mspiep01]

Ahhh! This is great news and I figured it had something to do along the lines with license type. I'll update the log owner to a queue or one of my integration users and see if the error subsides!

[jongpie]

@mspiep01 let me know updating the owner works for you! And is there any chance that you've been able to reproduce this issue in a sandbox? Or has this only been happening in your production org?

[mspiep01]

@jongpie I've not seen it quite yet in a sandbox, but it may be due to the sporadic nature and lesser volume.
Since changing the default log owner to myself, I have not seen this error.

[mspiep01]

@jongpie sad news, I'm the default log user and have received 4 errors in the past 48 hours

[jongpie]

@mspiep01 thanks for the update, even if it is sad news. Just to confirm, how did you configure yourself as the default log owner?

[jongpie]

@mspiep01 sorry 1 more follow up question! In the Apex error emails you're receiving, does the email specify where the error is coming from (like an Apex class name, line number, etc.)?

[mspiep01]

@jongpie I set myself as the Log Owner in NL Settings.

As far as the error email, this is all we get.

[jongpie]

Thanks @mspiep01 for confirming that you set yourself as the owner in the settings - I figured that was the case, but just wanted to be sure. I really should improve those error emails, they're not unhelpful without some more context😆

Even though you're still getting the errors, I'm going to proceed with the queue idea that I previously mentioned. I'm hoping that will solve the issue for you, although I'm still not sure why the error is happening for you when you've set yourself as the Log Owner via the settings. I'll be working on this more this week to see if I can figure out any other explanations for the ongoing errors, I'll keep you updated.

[jongpie]

@mspiep01 another update for you - I've created PR #560 to try to address this issue. I'm still finishing some testing & code cleanup, but I'm hoping to release this in the next few days. I'll let you know once it's been released!

[jongpie]

@mspiep01 there's some embarrassing & unfortunate news - I had forgotten that queues can't be included in managed packages, so including a default queue might not be feasible (since Nebula Logger has both an unlocked package and a managed package)....

For now, I'm going to put PR #560 on hold for the moment, and instead I'm going to look into improving the content of the email notifications being sent (like in your screenshot) so it includes more details. Since you've already set yourself as the Log Owner in the custom settings, it's still strange to me that you're continuing to receive the emails notifications. My hope is that improving the emails might give more insight on how exactly this is happening in your org.

Apologies that this has been (and continues to be) such a weird headache to deal with! I'll keep you updated on my progress with improving the email notifications.

[jongpie]

@mspiep01 based on our discussion a few weeks ago, it sounds like this isn't impacting you any more. I think I'm going to close out issue #545 and PR #560 for now, since my attempted solution doesn't work for the managed package. If/when this becomes an issue again, I can revisit it.

Let me know if that works for you!