Why:
We need to clear associated rails cache keys in order for changes to be
ready to be seen on the views
How:
* Just an after_save callback to a private method
Why:
Somehow we're seeing communities without proposals at production. We
must find why and fix it, but first we need to throw a 404 at the user
instead of a 500 internal server error
How:
First catching the scenario of non-existent communitable at the
controller and raising a 404 error. Secondly preventing the author_id
access over a possibly nil object, this is a smell but it can't be
easily fixed right now... we need to correctly implement a relation
between Community and communitable and avoid the multiple occurences of
`community.from_proposal?` in the codebase that makes it impossible to
extend to a fourth communitable model.
Why:
The html tags weren't removed from the text that was rendered at the
social metatags (twitter & facebook), neither scaped so adding a quoted
text would endup breaking the metatag content and writting in plain
sight the description at the browser view.
How:
Saniziting the text and truncating it afterwards since we don't need to
send more than 140 chars for twitter/facebook social cards.
Why:
The Admin Budget form has a submit button for saving the record, adding
another submit input to destroy the record actually adds to the html:
`<input type="hidden" name="_method" value="delete">` and it collides
with the save button, forcing it to perform a destroy instead of save.
Previously the destroy button was not in the same div as the save button
How:
Just changing the Destroy from a button_to to a link_to.
During a Participatory Budget, some users are getting confused and
creating a proposal instead of a budget investment. This intermediate
page should help them create investments
Adding a feature flag just in case other forks don’t need this feature
and setting seeds and dev_seeds for appropriate initial setup
This method is already existent in the application_controller but it
seems a little overkill to create a concern just for this method
Maybe when we have multiple method it makes sense to create a nice
controller. Another option would be to make the
management_base_controller extend from the application_controller
This is a preventive change which will be useful once the rake to
migrate from `spending_proposals` to `budget_investments` is complete
As after running that migration, old `spending_proposal` budgets will
have a newer `id` than the existing budgets. And therefore the last
budget will be one of those migrated from the old `spending_proposal`
model
By ordering by `created_at` and probably updating the `created_at`
attribute in the rake that migrates `spending_proposals` to
`budget_investments`, we will have a coherent order for budgets
