trolando
commented
6 years ago Comments have been used in addition, and an odd bug was fixed also. Turns out that the LDAP data Janeus returns is typed as bytes and needs to be decoded to strings! Very unexpected.
OK so this is a pretty big one. The point was mainly to introduce an improved Unsubscribe feature but there were a couple other things that also had to be done, so to make things smooth it's just one PR.
Maybe @mathemaat can especially take a look at this.
First I fixed an issue with the new logo. The sizes are now different. Important: this might also affect the templates that are in the live app and this should be checked manually by going into the Templates section in the Admin of the website.
Second I had an old work-in-progress branch that I now polished and finished, which lets developers work on Hemres without requiring a fullblown Mezzanine installation. I installed a bunch of fallbacks, mainly to replace the SiteRelated functionality Mezzanine offers. Hemres also uses Mezzanine's "fullcalendar" to query events and this is now nonfunctional without Mezzanine (as it should be).
Now for the Unsubscription, I added a secret and unique token that is associated with each subscriber. I created a Migration for this, so you have to run "manage.py migrations" to ensure that things are proper and good in the database. OK so this token is automatically created when saving and I ensured that when we are going to use this (in the commits after that) the function create_or_get_unsubscribe_token automatically creates it if it has not yet been set. This ensures we don't run into migration problems.
Then I added a few views that handle the desired behavior. We have several requirements that are in a bit of tension. The important thing is that after clicking the Unsubscribe button, a user may not be asked to enter stuff or get more emails or other burdens. They must be able to immediately unsubscribe and get out of the system. This kills ALL subscriptions of that subscriber. The second requirement is that if someone forwards a newsletter and the receiver uses unsubscribe, then they could unsubscribe the subscriber without them knowing it. We solve this problem by sending a final email to confirm their unsubscription, this is also the final email that is sent and the reason why we do this is made clear in the text. The third requirement is that a user may want to only change their subscriptions (we have multiple newsletters) and in this case, they can simply choose a second option to receive an email that brings them to the original functionality of changing one's subscriptions.
Finally, I modified the NewsletterToList such that the subscriptions URL now points to the new functionality but using token DUMMY_TOKEN. When sending to actual subscribers, this text is replaced by the token of each subscriber.