The condition `params[:page_id] != 0` didn't work properly when editing
the homepage because in that case the parameter was `nil`, and the line
`SiteCustomization::Page.find(@card.site_customization_page_id)` raised
an exception because it couldn't find a page with a `nil` ID.
Fixing the issue while maintaining the check against `0` lead to complex
code, and so allowing `nil` in the database and assuming cards with no
`site_customization_page_id` belonged in the homepage seemed to be the
easiest solution.
We accidentally changed the schema when modifying an existing migration.
It wasn't critical because we're going to remove that table in the
future, but it resulted in conflicts for users who had already run the
migration before its modification.
This commit fixes commit 4a7f479.
We'd rather keep the table so future data migrations work smoothly, so
we change the migration in order to create the translation table without
using models.
Generalize the BudgetInvestmentStatus model to Milestone::Status so it
is not specific to budget investments, but can be used for any entity
which has milestones. This is in preparation to make the Milestone
model polymorphic and usable by entities other than budget investments.
We can use the `config.authorize_with` option, so we don't need to copy
the controller in order to load and authorize resource.
Besides, only administrators can upload images, so we don't need to
track the image's user id.
With this commit we are logging which emails have already received the
newsletter
This could be important if something goes wrong sending the newsletter,
to be able to identify which users have already received the newsletter
and be able to skip them
We’ve had to add a new action to the Activity model (email) and add
paranoia features to be able to deal gracefully with the default
`with_hidden` scope in Activities[1]
[1]
https://github.com/AyuntamientoMadrid/consul/blob/master/app/models/acti
vity.rb#L2
