Details
-
Type:
Improvement
-
Status: In Progress
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 5.10.0
-
Fix Version/s: 5.14.0-b1
-
Component/s: Staff Interface
-
Labels:None
Description
People mess up email templates all the time, and there's no way to restore unless they install fresh and copy/paste from that fresh install.
We store email templates in the emails table. emails.company_id is the company ID. So, I think we could store these default templates with an ID of 0. On install, we should populate the emails table with another copy of the templates with company_id 0. Whenever we make changes to email templates, we will need to remember to update/create the same templates for company ID 0.
In the UI
- Add a red button with modal popup confirmation to the left of "Cancel" button called "Revert to Default".
- Add a bulk option on the template listing called "Revert to Default".
Reverting will replace the subject, text, html from the company_id 0 template. Do not replace from email, name, or remove any attachments, etc. Only subject, and html and text content.
Activity
As a counterpoint to my previous comment, plugins also create templates and it would be useful to store the defaults for those as well and the database would probably be the best place
A few thoughts on this:
- It will be more work with future upgrades to maintain a "default" template. Every time we make a change to a template we have to update the default, and the changes we make to templates are often string replacement so the updated template may not resemble the default. We'd have to run the same tasks against the templates and the default template, wherever this is stored (disk or mysql)
It might be better instead of doing this, to store a history of changes so that previous changes can be reverted to. The way that this would work is as follows:
- When a client accesses an edit template page, if there is no history stored for the template, immediately save it. (downside is that those upgrading can only revert back to the state at time of upgrade)
- When a client saves a template, also save a copy in history.
- Store a maximum of like 10 snapshots, rolling off the older ones as we go, but ALWAYS keeping the 1st snapshot.
- When editing a template, we would show a dropdown called "Select to Revert" or similar. Below that a list of snapshots by date/time. Selecting an option would replace the text (text/html) in the template but NOT save it. User must save the template to store this snapshot. Not saving it immediately allows them to click through different snapshots to evaluate which one to restore before restoring it.
So, let's think about this other option and consider revising this task.
Downsides
- No option to revert to "default" except for those that install after this release
- Changes to templates will not become part of a snapshot until the template is re-saved
Upsides
- New installs will always be able to revert to the original (but does not include migrations later)
- Can revert not just back to the original template, but the original + the last 9 saves.
- More history to revert that just "default".
Paul Phillips
added a comment - A few thoughts on this:
It will be more work with future upgrades to maintain a "default" template. Every time we make a change to a template we have to update the default, and the changes we make to templates are often string replacement so the updated template may not resemble the default. We'd have to run the same tasks against the templates and the default template, wherever this is stored (disk or mysql)
It might be better instead of doing this, to store a history of changes so that previous changes can be reverted to. The way that this would work is as follows:
When a client accesses an edit template page, if there is no history stored for the template, immediately save it. (downside is that those upgrading can only revert back to the state at time of upgrade)
When a client saves a template, also save a copy in history.
Store a maximum of like 10 snapshots, rolling off the older ones as we go, but ALWAYS keeping the 1st snapshot.
When editing a template, we would show a dropdown called "Select to Revert" or similar. Below that a list of snapshots by date/time. Selecting an option would replace the text (text/html) in the template but NOT save it. User must save the template to store this snapshot. Not saving it immediately allows them to click through different snapshots to evaluate which one to restore before restoring it.
So, let's think about this other option and consider revising this task.
Downsides
No option to revert to "default" except for those that install after this release
Changes to templates will not become part of a snapshot until the template is re-saved
Upsides
New installs will always be able to revert to the original (but does not include migrations later)
Can revert not just back to the original template, but the original + the last 9 saves.
More history to revert that just "default".
Personally I don't think the database is the right place for static content like this. I'd rather see it in a file though I don't have a great place for it. Perhaps /lib or /config.