Custom forms list
Updated DB schema (not yet implemented in the server, which means that most of the server is not broken).
- custom forms are independent of a list
- order and visibility of fields is now in custom_fields
- first_name and last_name has been turned to a regular custom field
Added support for ajax-based server side validation (useful for validation of emails, duplicate usernames, etc.)
User form more or less ready in the basic version (i.e. without permission management)
During code refactoring for selectable
unsubscription feature code:
`!campaignId || status > 2` was wrongly refactored
to:
`subscription.status !== Status.SUBSCRIBED`
Link:
a6d25e668b (diff-5af9fe5dfae76c093530c92e3d7404e1R496)
The idea is that REST handlers always fail with throwing an Error (subclass of InteroperableError). The InteroperableError contains type and data field which are JSON-serialized and sent to client. It's up to the client to interpret the error and choose an appropriate way to present it.
Sending emails moved completely to controller. It felt strange to have some emails sent from the controller and some of them from the model.
Confirmations refactored to an independent model that can be potentially used also for other actions that need an email confirmation.
I also scraped the "auto" parameter which automatically submits the unsubscription form when the link is clicked in a campaign email. Instead, I introduced the
unsubscription options ONE_STEP, ONE_STEP_WITH_FORM, TWO_STEP, TWO_STEP_WITH_FORM. The options without "_WITH_FORM" shall behave like when called with "auto".
This functionality is to come. Currently it behaves as ONE_STEP_WITH_FORM.
It allows defining report templates and then create reports based on the templates.
A template defines:
- parameters - to be set in the report (currently only selection of campaigns, in the future to be extended to selection of lists/segments, and selection from pre-defined options)
- data retrieval / processing code (in Javascript)
- rendering template (in Handlebars)
This main functionality is accompanied by a few minor tweaks here and there. Worth notice is the ability to use server-side ajax table s for multi-selection of campaigns. This is meant for reports that compare data across multiple campaigns. This could possibly be even used for some poor man's A/B testing.
Note that the execution of custom JavaScript in the data retrieval / processing code and definition of custom Handlebars templates is a security issue. This should however be OK in the general case once proper user management with granular permissions is in. This is because definition of a report template is anyway such an expert task that it would normally be performed only by admin. Instantiation of reports based on report templates can be then done by any user because this should no longer be any security problem.
