Add Submission Log Tokens to Email Handler

Hello!

This indeed sounds like a nice & cool feature to have. There ticket can be chunked into 2 pieces: get the tokens replacement working for log entries and make a log entry available from within an email handler. I'd like to propose the implementation in the following way:

The tokens part is rather simple, just to code it.

The other part, making the log entry available from within an email handler:

• Let WebformSubmissionStorageInterface::log() return the ID of the just inserted log message.
• Then we should see how WebformSubmissionStorage::doPostSave() can pipe it down into $this->invokeWebformHandlers('postSave', $entity, $update); . This would mean that we have to introduce an extra argument in WebformHandlerInterface::postSave(). Probably some kind of $options = [] would do it. So we can use it for future necessities too.
• At this point it will be available from within the handler.
• Some extra adjustments will have to be done to WebformHandlerMessageInterface::getMessage() because right now it only allows to generate the email wording on the submission and nothing else. We'd have to inject into there the log entry too so it can be sourced into token replacement $data.

I'll try to code it.

Okie dokie. Here's the 1st stage #2946132: Improve API for working with submission log entries.

I will probably create a few tickets that will be targeted to achieving your goal, infroger. I'll just be doing through a series of issues. Per jrockowitz guideline that's the best way to do it (it's simplifies a little bit ours, developers, lives).

Hey, Jacob!

In the meantime, I think we could start discussing possible implementation approach for tokens support, or at least let me document it here while I have it vivid in my mind. I would like to introduce a new token type: 'webform_submission_log' (which roughly would correspond to the return of WebformSubmissionLogLogger::load()). I would pack it with necessary tokens (message, timestamp, user, etc.)

And then I'd just plug it into 'webform_submission' token type with something like the following constructions:

• [webform_submission:webform_submission_log_latest:message], for e.g. to display the message of the latest log for a given webform submission
• [webform_submission:webform_submission_log_recent:5:timestamp], for e.g. to display the date of the 5th latest log for a given webform submission

By 'plugging' it in this way onto 'webform_submission' token type we make it available to Email handler and in fact wherever else where 'webform_submission' token is present (which is damn cool).

This is my current implementation plan.

I am little unsure about this feature. This seems like an edge case which could be handled in custom code or a dedicated contrib module. I am not saying no but we should ask how and why this feature should be in the core Webform module. To accomplish the initial request the token could get fairly complex. The token syntax might need to be something like[webform_submission:log:latest:OPERATION:HANDLER_ID:VALUE]

For example, to pull updated and submitted would require the below code.

Updated on: [webform_submission:log:latest:submission created:date:medium]
Updated by: [webform_submission:log:latest:submission created:user:name]

Submitted on [webform_submission:log:latest:submission updated:date:medium]
Submitted by: [webform_submission:log:latest:submission updated:user:name]

The one-off solution would be to create a custom module with a [CUSTOM_webform_submission:log] token that just outputs the data that they need.

If someone needs to track who updated, what, and when maybe revisioning needs to be enabled (in a dedicated contrib module) for webform submissions.

I am also worried about these webform submission log tokens would be exposing too much information. For example, a site builder who can only place webforms and customize the confirmation message can now see the logs by using these token. I know this is scenario is also an edge case.

I see your logic, Jacob

And would you be willing to introduce at least basic tokens support for logs? Such as I depicted in my previous comment or even less? Or you think anything related to tokens of logs should rather exist in another contrib module? With the existence of webform_submission_log.module to me it feels there is a nice corner, i.e. that submodule, where we could place some degree of support for tokens.

And as far as access bypass - this is right! Probably the all log related tokens should additionally check user permissions before blindly displaying requested information.

I think these tokens that are for edge cases should be built outside of the core webform module.

If we address #2946132: Improve API for working with submission log entries, it should be easy for a developer to write a custom query and append submission log data to an email or submission.

Working on #2946132: Improve API for working with submission log entries seems more valuable and working towards adding a user-specific submission log tab to a user's dedicated submission page could help address GDPR requirements.

Jacob, do we then close this issue as 'won't fix' or what destiny do you see for it?

Now that there is an API this request is easier to handle via custom code. I vote to close this ticket.

There is a decent amount of documentation on How To Create A Custom Token In Drupal 8?