Naming two variables the same way is confusing at the very least, and
can lead to hard to debug errors. That's why the Ruby interpreter issues
a warning when we do so.
Some of our team members don't like using `do...end` for scopes, and
some other team members don't like using `{ ... }` for multi-line
blocks, so we've agreed to use class methods instead.
Moderate legislation proposals
- added a controller for moderation/legislation
- updated view to appropriate link + added route
- added a spec
- Feature test
- test for faded
- javascripts for visual effects
This way we write the tests from the user's point of view: users can see
(for example) a proposal with the title "Make everything awesome", but
they don't see a proposal with a certain ID.
There are probably dozens, if not hundreds, of places where we could
write tests this way. However, it's very hard to filter which ones are
safe to edit, since not many of them have an HTML class we can use in
the tests, and adding a class might generate conflicts with CSS styles.
So, for now, I'm only changing the ones allowing us to cleanly remove
useless assignements while maintaining the code vertically aligned.
This is one of the most strange behaviours in ruby: if a variable
doesn't exist, assigning to itself will return `nil`.
So a line like:
mdmkdfm = ooops if mdmkdfm.respond_to?(:uiqpior)
Surprisingly will not raise any errors: the nonexistent `mdmkdfm`
variable will be evaluated to `nil`, `mdmkdfm.respond_to?(:uiqpior)`
will evaluate to `nil.respond_to?(:uiqpior)`, which will return `false`,
and then the line will be evaluated as `mdmkdfm = ooops if false`, which
will return `nil`.
Maybe in the future Ruby will change this behaviour. We hope CONSUL is
now in better shape if that ever happens :).
Joining two scopes with `+` does not remove duplicate records. Luckily
now that we've upgraded to Rails 5, we can join scopes using `.or`.
The test was testing for the presence of elements, bud didn't test for
duplicate records. Testing the exact contents of the array revealed this
behaviour.
When `valuator_group` was `nil`, `[valuator_group&.investment_ids]` is
evaluated to `nil`, and so we were adding an extra element to the array.
We could add a `compact` call to the resulting array, but I find it
easier to convert `nil` to an array using `to_a`.
When creating a budget investment with an unverified manager (for
example, a manager who isn't part of the local census), there's a
request to `Budgets::InvestmentsController#suggest`. Since the manager
isn't verified, suggestions can't be obtained.
There are serveral ways to fix this problem:
* Add a `suggest` action to Management::Budgets::InvestmentsController,
doing the same thing the main `suggest` action does.
* Give unverified users permission to access investment suggestions
* Give managers permission to access investment suggestions
I've chosen the last one because I thought it was simple and only
changed existing behaviour for managers, but any other solution would be
as valid. I haven't added the `phase: "accepting"` condition to keep it
simple, since a read-only action like this one in the management portal
isn't gonna create security risks.
Investments can be reclassified to a different heading during the participatory budget process.
Whilst we are recording this change of heading in the `previous_heading_id` attribute, we are only keeping the _last_ heading. If there are multiple reclassifications we lose this chain of reclassifications.
In this commit we are adding an `original_heading_id` attribute, that will only be set once, when creating the investment, and will not get lost with multiple reclassificaitons of an investment.
When we were inserting a row or replacing an existing one (just like we
do when we click the link to select an investment), we were entering a
row containing all columns, and all of them were displayed even if they
had been excluded using the column selector.
This caused the table to move in a strange way, which sometimes made the
investment selection tests fail.
