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.
Using `stub` from rspec-mocks' old `:should` syntax without explicitly
enabling the syntax is deprecated. Use the new `:expect` syntax or
explicitly enable `:should` instead
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
Create a new Budget::Phase model that:
* Stablishes a relation with its budget
* Stablishes relation with two other Budget::Phases (previous and next)
* Validates basic dates range, kind and description rules.
* Adds scopes to get the ones enabled as well as each individual phase
Create a factory that generates a basic and valid Budget::Phase
Create a model spec that checks kind, date range and budget validations.
This spec used to pass, because even though there were no budgets, as
Budget.current returned an array, it gracefully handled situations
without budgets
Now we assume that there can only be a single current budget, and so
calling any method of budget will raise an exception unless there is a
current budget present
Valuators should not access this page when there is no budget present,
however it might be wise to create an issue to cover this case, just in
case
Before we could have multiple current budgets, as we now only have one
current_budget, some specs broke.
As there is no need to display multiple budgets to Valuators, only the
current budget is necessary, we can remove arrays and assume that only
a single budget, the current budget, is displayed to Valuators
In the specs, some investment were missing a heading_id, thus creating
another unexpected budget
By explicitly setting the heading_id we can control better which
budgets are created in each test
Before Budget.current could return multiple budgets, now there can only
be a single current_budget.
Adding the concept of open, which better reflects what the admin sees
in this page: A tab for open budgets and a tab for finished budgets
When there was only one budget this implementation worked fine
Nowadays there can be multiple budgets, and therefore the definition of
the current_budget has changed. It is no longer a budget that has not
finished, but rather, the last budget created that is not in the
initial drafting phase.
Budgets in the drafting phase are not considered the current_budget,
but rather a budget that is still being prepared and that soon will
become the current_budget
