Email notifications toggle API endpoint

[thedae]

This PR enables two new API endpoints to enable/disable email notifications (such as DO notifications):

GET /api/v3/email_notifications?api_key=abcd
Returns a JSON with the list of email notifications and the current status, for example:

{
    "notifications": {
        "do_subscriptions": true
    }
}

PUT /api/v3/email_notifications?api_key=abcd
Create or update a given list of notifications. This endpoint needs a JSON payload as request parameter, for example:

{
    "notifications": {
        "do_subscriptions": false,
        "some_other_subscription": true
    }
}

You don't need to always provide the complete list of notifications to update them.

[rafatower]

LGTM, just left minor comments, nothing blocking 💪

[rafatower]

nitpicking: you can use the inclusion validation helper: https://guides.rubyonrails.org/v4.2/active_record_validations.html#inclusion

[thedae]

I'm having some issues applying this suggestion: in the spec file now I have to mock the constant instead of the valid_notification method, and I can't figure out a good solution to achieve that

Thanks for the feedback thou :)

[rafatower]

then I guess you have two options: rely on rails doing the validation and not testing it, or keep it "as is" :)

(no big deal)

[thedae]

I prefer to test it, even if the validation method is not the ideal, so I'm going to keep it as is

[rafatower]

from my ignorance, why is this needed?

[thedae]

Probably a leftover of a copy&paste from other controller, let me check and delete it

[rafatower]

I think this is not needed

[rafatower]

(I was wondering if this on_delete: :cascade collides with user model dependent: :destroy, but I see there's even a test for it 👍 )

[amiedes]

I'm leaving a couple of comments 👀

[amiedes]

I think the , only: [:show, :update] is not needed, as for the time being this controller only has those two actions.

[thedae]

You're right, it's useless

[amiedes]

Keep in mind you're overriding the behavior of the email_notifications= which Rails creates automatically when you declare the association:

has_many :email_notifications

Not sure if this might cause issues. The build method might come in handy if you want to try it: https://apidock.com/rails/ActiveRecord/Associations/CollectionProxy/build