Post Reply Bug in E-mail Settings Page
33453 cr points
Send Message: Send PM GB Post
M / ミシガン
Posted 7/25/15 , edited 7/25/15
Just wanted to point out what I think is a bug in the E-mail Settings page. The e-mail settings page that I'm referring to is the one that u get re-directed to from clicking on the "Unsubscribe" or "Manage Email Subscriptions" links on one of CR's emails that they send out for Queue Updates, Newsletters, Daily Deals, etc. Here's a pic of the E-mail Settings page that I'm referring to:

Now if you make any changes to any of the settings on this E-mail Settings page (checking or unchecking any of the boxes - even if it's just 1 change), it also unchecks all of the boxes for the notifications that one would receive on CR. The below pic is an example of everything that got unchecked for me (which was everything):

I've tested this out quite a few times on Firefox on my laptop, and each time, everything on my notifications for CR would get unchecked.


I remember a couple weeks ago receiving guest book messages and not receiving any notifications for it, and being dumbfounded as to the reason for it. But mystery solved.
Otter Modder
51191 cr points
Send Message: Send PM GB Post
24 / M / Florida
Posted 7/25/15 , edited 7/25/15
So with your info I was able to narrow down the cause of this. Basically there is some weird overlap with the settings update calls.
The three (there is a third) pages involved in this all call different parts of the api:
This one:

uses RpcApiUser_EditNotificationSettings with the options being called enable[1]: 1 and enable[100]: 100 with the lower section being email[1]: 1 and email[2]: 2

This one

uses RpcApiUser_UpdateEmailInfo with the options being things like email_sub[2]: 1 (the 1 actually makes sense in this one).

The final page being the one linked via the emails (I can't link it for obvious reasons) seems to be some weird mix of the two including all the email options from both but using a different Api call of RpcApiUser_EditEmailSettings with options of email[1]: 1 pattern for the first set and the same email_sub for the second set.

Now the importance of all this is that all of these calls only supply the options if they are enabled and assume that they are disabled otherwise. So the third page, which uses a hybrid call of the other two, sets all of the options of the first page to disabled since they aren't included in the call. Since both of the email option pages are served over http while the notifications page is https, you can't simply include the userdata for selected options so the only solutions would be to fully separate the api calls instead of just delegating like they are now or to have it submit values for both enabled and disabled and stop assuming a default of disabled.

The first choice would only edit the backend api code since it already has it's own function name. The second choice would involve editing some of the template files, but either change should only take a couple of hours at max (with testing).

I'll forward this to CS and hope it gets fixed quickly, but in the meantime you should just avoid that page. Thanks for the very specific bug report.
You must be logged in to post.