"email in category" resets to 0


(James Milligan) #1

Using 0.9.9.10, non-docker install on Ubuntu 13.10 (I realise non-docker installs aren’t supported, so if someone could reproduce that would be appreciated).

Setting “email in category” to a category name (e.g. meta) saves fine with the tick, but on a page reload, it has the value 0 and remains “overridden” in style. Emails continue to appear on the forum fine, I think just as uncategorised.

What should be going into this field?


How do you allow for unknown/non-users to post via email?
(Kane York) #2

If you pick a different category, does it have a different numerical value? Just curious…


(James Milligan) #3

Nope, back to 0 on the categories I’ve tried.

In the “logs” area, it shows this: New: adverts, Previous: 0
Changing it straight away gives this: New: meta, Previous: 0

i.e. it generated the log entry for the change to adverts, but presumably it didn’t “stick”.

Looks like something after the log entry is generated? I’m not familiar with Ruby in the slightest, only PHP, so I’m like a fish out of water here :-/


(Austin Hamilton) #4

I’d like to know this as well; I’ve had the same issue. It initially made me think that the categories were supposed to be represented by numbers, but putting a 1 or a 2 doesn’t redirect the emails. Is it supposed to be integer only input or something? How are we intended to fill this out? Just by the name of the category?

(I am also using 0.9.9.10 on docker)


(James Milligan) #5

Cheers for moving to bugs @riking. Glad it’s not only me!


(James Milligan) #6

Just to note that this still happens (0.9.9.11, pulled just a few minutes ago)


(James Milligan) #7

Possibly some useful information for you (attempting to update email_in_category from the ‘default’ of -1 to ‘meta’):

LOG:  execute a20: UPDATE "site_settings" SET "name" = $1, "updated_at" = $2, "value" = $3 WHERE "site_settings"."id" = 43
DETAIL:  parameters: $1 = 'email_in_category', $2 = '2014-07-04 10:00:16.322484', $3 = '0'

LOG:  execute a21: INSERT INTO "user_histories" ("acting_user_id", "action", "admin_only", "created_at", "new_value", "previous_value", "subject", "updated_at") VALUES ($1, $2, $3, $4, $5, $6, $7, $8) RETURNING "id"
DETAIL:  parameters: $1 = '1', $2 = '3', $3 = 't', $4 = '2014-07-04 10:00:16.491555', $5 = 'meta', $6 = '0', $7 = 'email_in_category', $8 = '2014-07-04 10:00:16.491555'

(on latest git)


(Jeff Atwood) #8

@riking can you put this on your list of things to repro and fix next week?


(Kane York) #9

Okay. Seems to me like an incorrect conversion to int in the settings…


(James Milligan) #10

Great stuff, thanks @codinghorror + @riking. If I can help any further at all let me know. If I knew Ruby at all I’d try fixing it myself but I am but a lowly PHP guy :’(


(James Milligan) #11

@riking I guess your latest commit nullifies this bug - I’d meant to suggest the idea, but never got round to it. Makes sense though. Cheers :slight_smile:


(Kane York) #12

Yup - it seems that the setting was actually the category ID, but none of the text told you that. Go ahead and update once this commit hits the tests-passed branch.


(James Milligan) #13

Yep I’ve got the test open in one window to give it a shot. I thought @Drum had tried with a category ID, but maybe they weren’t 1 or 2 on his install. Anyway, will update when it’s live. Appreciate it :slight_smile:


(James Milligan) #14

Doesn’t look like this has been included in the repo yet - is this being revisited?


(Kane York) #15

Hm, it seems the code has a merge conflict. I’ll get to it today, I think.


(James Milligan) #16

Cheers. Off on holiday for a couple of weeks, so apologies in advance for any delays in checking this out. Appreciate your work on it!


(Sam Saffron) #17

Whats going on here, is it fixed?


(Kane York) #18

This topic is now closed. New replies are no longer allowed.

The setting was removed, as it was confusing - it was expecting a category ID, which is not surfaced in the UI anywhere. Email-in addresses are now entirely in the category settings.