This is consistent to what we usually do. Also, we're applying the same
criteria mentioned in commit 72704d776:
> We're also making these actions idempotent, so sending many requests
> to the same action will get the same result, which wasn't the case
> with the `toggle` action. Although it's a low probability case, the
> `toggle` action could result in [selecting a proposal] when trying to
> [deselect] it if someone else has [deselected it] it between the time
> the page loaded and the time the admin clicked on the "[Selected]"
> button.
We were using `prepend: true`, but it doesn't seem to be necessary.
We were also loading the draft versions twice in the index, so we can
remove the line loading them a second time.
When customizing CONSUL, one of the most common actions is adding a new
field to a form.
This requires modifying the permitted/allowed parameters. However, in
most cases, the method returning these parameters returned an instance
of `ActionController::Parameters`, so adding more parameters to it
wasn't easy.
So customizing the code required copying the method returning those
parameters and adding the new ones. For example:
```
def something_params
params.require(:something).permit(
:one_consul_attribute,
:another_consul_attribute,
:my_custom_attribute
)
end
```
This meant that, if the `something_params` method changed in CONSUL, the
customization of this method had to be updated as well.
So we're extracting the logic returning the parameters to a method which
returns an array. Now this code can be customized without copying the
original method:
```
alias_method :consul_allowed_params, :allowed_params
def allowed_params
consul_allowed_params + [:my_custom_attribute]
end
```
These changes fix a bug that causes categories
of a legislation process to be wiped on update
of the process. It also adds a regression test
for this fix.
The new CSV report was more configurable and could work on proposals,
processes and comments. However, it had several issues.
In the public area, by default it generated a blank file.
In the admin section, the report was hard to configure and it generated
a file with less quality than the old system.
So until we improve this system, we're bringing back the old investment
CSV exporter.
This commit reverts most of commit 9d1ca3bf.
The current tracking section had a few issues:
* When browsing as an admin, this section becomes useless since no
investments are shown
* Browsing investments in the admin section, you're suddenly redirected
to the tracking section, making navigation confusing
* One test related to the officing dashboard failed due to these changes
and had been commented
* Several views and controller methods were copied from other sections,
leading to duplication and making the code harder to maintain
* Tracking routes were defined for proposals and legislation processes,
but in the tracking section only investments were shown
* Probably many more things, since these issues were detected after only
an hour reviewing and testing the code
So we're removing this untested section before releasing version 1.1. We
might add it back afterwards.
We were very inconsistent regarding these rules.
Personally I prefer no empty lines around blocks, clases, etc... as
recommended by the Ruby style guide [1], and they're the default values
in rubocop, so those are the settings I'm applying.
The exception is the `private` access modifier, since we were leaving
empty lines around it most of the time. That's the default rubocop rule
as well. Personally I don't have a strong preference about this one.
[1] https://rubystyle.guide/#empty-lines-around-bodies
Having exceptions is better than having silent bugs.
There are a few methods I've kept the same way they were.
The `RelatedContentScore#score_with_opposite` method is a bit peculiar:
it creates scores for both itself and the opposite related content,
which means the opposite related content will try to create the same
scores as well.
We've already got a test to check `Budget::Ballot#add_investment` when
creating a line fails ("Edge case voting a non-elegible investment").
Finally, the method `User#send_oauth_confirmation_instructions` doesn't
update the record when the email address isn't already present, leading
to the test "Try to register with the email of an already existing user,
when an unconfirmed email was provided by oauth" fo fail if we raise an
exception for an invalid user. That's because updating a user's email
doesn't update the database automatically, but instead a confirmation
email is sent.
There are also a few false positives for classes which don't have bang
methods (like the GraphQL classes) or destroying attachments.
For these reasons, I'm adding the rule with a "Refactor" severity,
meaning it's a rule we can break if necessary.
Updating it required reorganizing the form so translatable fields are
together.
We also needed to add a `hint` option to the form label and input
methods so the hint wouldn't show up for every language.
Finally, the markdown editor needed to use the same globalize attributes
as inputs, labels and hints, which adds a bit of duplication.
The `update` action is usually expected to behave the same way it does
everywhere else, which is updating a record using the `params` hash.
The name `toggle_select` comes from the name we use in a similar
situation for budget investments.
