|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000910||v3.0 Release||[All Projects] General||public||2011-07-31 11:14||2013-10-31 06:19|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
|Target Version||Fixed in Version||3.0.0|
|Summary||0000910: put ntotification emails into separate php file for better update handling|
|Description||I think the emails are a good point for individual coding.|
It would be nice if they could be put into a file/class only for email notifications and included into the other code.
That way, the filename to include could be given as system value e.g. email.defauöt.php could be included as default, and other filenames for modified vers entered into a field in sysadmin.
Advantage: we won't have to touch core code to maintain our email code changes after every update. Similiar to email templates in other oss software, but we don't need such a complicated approach..
|Tags||No tags attached.|
Last edited: 2011-08-09 12:51
Completely agreed.. it's on the agenda for v3.0 in September.
The class - classes/w2p/Output/EmailManager.class.php - is an attempt to do just that. I see it working out as three steps:
- First, collect all the email, etc templates to one place (that classes);
- Next, flesh out a token-based replacement system when we can take a template and feed in the data and get a correct email out;
- Finally, move all the email templates into the database and build a simple interface for editing them in the admin.
|This is getting merged into core later today;|
|2011-07-31 11:14||opto||New Issue|
|2011-07-31 20:58||caseydk||Relationship added||child of 0000154|
|2011-07-31 20:59||caseydk||Project||v2.4 Release (Closed) => v3.0 Release|
|2011-07-31 21:07||caseydk||Note Added: 0002102|
|2011-08-09 12:51||caseydk||Note Edited: 0002102|
|2011-09-27 23:50||caseydk||Status||new => assigned|
|2011-09-27 23:50||caseydk||Assigned To||=> caseydk|
|2011-11-12 22:24||caseydk||Note Added: 0002289|
|2011-11-12 22:24||caseydk||Status||assigned => resolved|
|2011-11-12 22:24||caseydk||Resolution||open => fixed|
|2013-08-28 11:13||caseydk||Fixed in Version||=> 3.0.0|
|2013-10-31 06:19||caseydk||Status||resolved => closed|