Make notification email more user friendly

Continuing the discussion from Set up emails and easy email delivery:

Currently it is complex for and end user to setup a notification email. This is because it requires to write the PYSON Condtion, which is normally hard complex for more advances users.

I think we should think some way to define pyson expressions for most common notification triggers, so the user can select them from a preconfigured list. Some common expressions will be:

  • Once the invoice is posted
  • Once the sale is confirmed
  • When a shipment is packed/sent.

The idea is that each module defines it’s owns expression, so when activating the module the trigger conditions are automatically loaded. It should be also possible to create expressions on the user interface.

Of course, we should include a way for adavanced users to write it’s own pyson expressions.

Althought this can be solved by custom modules, I think it’s worth discussing to see if we can find a common solution for most common cases.

Toughts?

So the idea would be to create predefined and reusable triggers but without action.
We could have a model ir.trigger.template that the user could select instead of filling all the trigger fields. When a template is selected, the fields are filled. The templates will be linked to a specific model.

Yes but this is only the starting point. Having the template without values is useless.
So we should define some templates on the modules and keep them up to date.

We may start only for Workflow modules, to allow a notification on relevant transitions and then keep adding more once we find them usefull.

So you propose to set values via on_change and let the user edit them? Or make them readonly?

Agree. We can define a template as:

  • Model:
  • Condition

Then the user can use the checkboxes to decide when the trigger should be executed.

All of that. We set via on_change the value when a template is selected and make the values readonly (or even invisible). And let them be edited if the template is unselected.

I think the “when” should also be part of the template because it is a technical choice which may be linked to the specific workflow etc.

What would help me a lot would be

  • When the user clicks on a “Send” button
    I think it would solve my case.

So this proposal will fit. Having a second confirmation button to click is not really a big deal.

I’ve filled Issue 9320: Add trigger templates - Tryton issue tracker with an implementation of templates and also some template examples for the account_invoice module.

IIUC you want to manually trigger the email notification, right?

I think we should add a flag to email notifications to allow to trigger them manually. When the flag is checked a new option is available on the model actions. Selecting the action will manually send the email notification.

1 Like

Exactly. I think this would fit my generic objective to speed up and standardize the way I send proposals, orders and invoices to my customers.
Because I’m not familiar with notification_email, I’m wondering how to, cc and bcc are linked to party’s contacts, and if we may need to add some information in party’s contact to pick the right addresses for each document.

Sorry I didn’t read Add sale flag on party contact mechanisms
which perfectly answers the case.
Thank you.

I do not like this proposal.For me, it overlaps with sending email from the client but with less flexibility. Also notification is about changes so it assumes the record has changed and it is in a certain state. Also the notification does not give any feedback about sending or not the email.
Now it may happen that a notification was not sent or wrongly sent, so we want to re-send it. In this case I think we should allow administrator to force a trigger on a specific record. But I do not see this as a feature for the casual user.

Yes, it may be seen as a simple implementation using a wizard.

But for me it also overlaps with automation of notification_email or marketing automation. When the number of records to send is low some users prefer to do it manually instead of automating.

@SISalp Won’t we better to automate your porses. For example, you can use the following notifications:

  • For proposals: When a sale is quoted
  • For orders: When a sale is confirmed
  • For invoices: When a invoice is posted

This will remove the need of having a button to manually send them.

This is a bit of topic, but I normally include the write_user of the record as BCC, so the user recieves a copy of the email that has been sent.

Yes, this is re-send email notification but I think this is only required when there is no email found for the recipient. Otherwise it won’t make sense to re sendit.

.

I understand this but in practice:
When the party is a private company, I send invoice by mail. It would fit.
When the party is part of administration, I post the invoice to Chorus-pro server
Sometimes, I think at first the party is administration, and I discover on Chorus-pro it is a private institute, and I send it then by mail.

This is doable:

  • If you use the account_fr_chorus, the trigger to send the notification should exclude party with the Chorus Pro boolean checked.
  • If you do not use account_fr_chorus then you can put a generic fallback email address for the invoice of the Chorus Pro parties. So we you receive the invoice on this mailbox, you know you have to put it manually on Chorus Pro site.

So with both workflow, everything is automated and the user does not need to decide what to do with the posted invoice.

So far, I don’t use account_fr_chorus because of the API and its certificate.
The case was about the fact, that despite the ‘no exception’ official rules, you often don’t know at first if you should re-encode invoice on Chorus Pro portal or send it. You try and correct.