Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

E-Mail notifications for editors are missing information on the element #162

Closed
MoritzLost opened this issue Sep 2, 2022 · 13 comments
Closed

Comments

@MoritzLost
Copy link

Describe the bug

We're seeing a bug in production where the e-mail notifications for editors are missing information on the element the submission is related to. The E-Mail template is mostly identical with the example in the documentation. We upgraded to Craft 4 and 2.0.0-beta.6 of the Workflow plugin recently, this error has started occurring after the update.

Every placeholder relating to the element is empty – specifically, {{ submission.owner.title }} and {{ submission.cpEditUrl }} are empty. {{ submission.editorNotes }} correctly contains the editor notes, though.

Unfortunately, I haven't been able to reproduce this in a development environment, but we're definitely seeing this in production with multiple unrelated users and entries.

Not sure what may be causing this. In the workflow overview, the submissions where this error occurred don't show the element they're related to, instead they just show [Deleted element]. So maybe the submissions are missing the relation to the element for some reason?

Steps to reproduce

Unclear.

Craft CMS version

4.2.3

Plugin version

2.0.0-beta.6

Multi-site?

No response

Additional context

No response

@engram-design
Copy link
Member

So this is one of the current pain-points with the submission process in general. Because we're acting upon everything with a draft entry, once the entry has been approved, it's published, and therefore removed. So the draft entry the submission has been related to since the submission was created is now gone.

We're probably going to have to switch out the reference to the deleted draft to refer to the canonical entry.

@MoritzLost
Copy link
Author

@engram-design So the placeholders in the email not working is to be expected at the moment? Or just the [Deleted element] issue?

I'm not sure if this is the whole story, though. In all our tests in the development environment, the notification emails worked fine and still do. If it's related to the issue you mentioned, wouldn't this mean that the notification emails could never work at the moment? I'm confused …

We're probably going to have to switch out the reference to the deleted draft to refer to the canonical entry.

Sounds like a good idea. Is there an ETA for this fix? At the moment, this is preventing the editor workflow from working properly. In lieu of the full rework mentioned in #156 and #158, having a temporary solution for the email notifications problem would be great.

I know the plugin is still in beta, so it's our fault for upgrading early. We couldn't wait for the stable release because several other issues and feature requests were tied to the Craft 4 update …

@engram-design
Copy link
Member

The issue is that it's both! The submission no longer has a reference to the owner, so the info in emails won't work, and it'll show the owner entry as being "deleted" (technically, the draft entry has been deleted).

It does seem a little strange, that's for sure. Some things to check:

  • Are you creating submissions from a brand-new entry, or creating a new submission from an existing entry?
  • Are you approving and publishing, or just approving?

No ETA yet sorry, but it does sound like maybe something else is going on if you're seeing different behaviours across different environments. If you can just check the above is the same for production/dev in your testing?

@MoritzLost
Copy link
Author

@engram-design Ok, I just tested all scenarios in depth:

  • Submission for a new entry
    • Approve & publish: Works correctly (Element visible in workflows list afterwards, email sent correctly)
    • Approve only: I get a 400 bad request for this one (see screenshot below), probably a different error. The approval still goes through and everthing else works correctly.
    • Reject: Works correctly (Element visible in workflows list afterwards, email sent correctly)
  • Submission for changes to an existing entry:
    • Approve & publish: This works correctly, but the element shows up as [Deleted element] in the overview after publishing, and I'm not getting any confirmation email at all even though I should (according to the settings).
    • Approve only: This one is strange. Approval works, but from the perspective of the editor the approval has no effect. The draft is still in draft stage, I see the approved draft submission in the history, but I can't publish the draft, I can only submit it again. Is this the intended behaviour?
      In this scenario, the email to the editor is sent correctly and contains all the information on the entry, probably because the draft is still present at this stage.
    • Reject: This one works and the email is sent correctly.

HTTP 400 Bad Request error (after selecting Approve only for a new entry):

http-400-error

So all in all, I'm a bit confused and I think there are a couple of things that aren't probably integrated into the Craft 4 publishing workflow yet. In particular, the HTTP 400 error, the missing email for approving a change to an existing entry and the behaviour of the Approve only option feel like separate issues to this one.

As a temporary workaround, we can probably use the Approve only option and then publish the approved draft immediately afterwards. This way, the email will get sent correctly, and the result will be the same. Still annoying that the workflow overview will only display [Deleted element], but the main issue for my client right now is the missing info in the email.

Anyway, hopefully this was helpful. Maybe you can do some additional testing and look into those errors, I don't think I've covered every angle here. Let me know if you need more information!

@engram-design
Copy link
Member

Thanks for the detailed write-up!

The "Approve only" issue should've already been taken care of, but I'll take another look.

I'll review all this and look to get this sorted ASAP.

@MoritzLost
Copy link
Author

@engram-design Thank you!

The "Approve only" issue #161 been taken care of, but I'll take another look.

Are you sure this is the same issue? This one mentions a database-level error, the error I was getting was completely different … anyway, let me know if you need me to test something or provide more information!

@MoritzLost
Copy link
Author

@engram-design Do you have any new information regarding the issues in this thread, or can you give an estimate when you will be able to work on them? My clients are still regularly facing this issue and I couldn't find a workaround that works well in every situation.

Let me know if you need any more information. Thanks!

@engram-design
Copy link
Member

@MoritzLost I don't have a quick fix available, sorry - but I am going to try and look at it this month.

@green17
Copy link

green17 commented Oct 18, 2022

I think we're seeing a problem like this where the IDs in the WorkFlow CP do match the entry being edited, we are using the submission queries to look up user's entire. @engram-design would this all be the same problem? we are on 2.0.0-beta.6.

@engram-design
Copy link
Member

@green17 Possibly, but it could be referring to the draft as opposed to the canonical entry, which would be valid.

@engram-design
Copy link
Member

This has been improved in 2.0.0-beta.8 now that we're saving the original canonical entry, which is switched back to once the draft has been applied (and therefore deleted).

@MoritzLost
Copy link
Author

@engram-design Thanks for the update! Looks like it resolves the issue in my dev environment. No more [Deleted element] in the submissions list, and the email notifications are correctly populated as well.

Haven't updated the plugin in production yet (waiting for #165 and #158), but I'm confident this will fix the issue there as well.

@engram-design
Copy link
Member

Nice one! And yep, best to hold off until the 2.0 release (for production) which should be about next week to round out these final round of changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants