These columns were causing Rails 5.2 to throw a warning when ordering by
them, as if they weren't valid column names:
DEPRECATION WARNING: Dangerous query method (method whose arguments are
used as raw SQL) called with non-attribute argument(s):
:"budget/investments_count". Non-attribute arguments will be disallowed
in Rails 6.0. This method should not be called with user-provided
values, such as request parameters or model attributes. Known-safe
values can be passed by wrapping them in Arel.sql().
This change also makes their names consistent with the rest of our
tables and columns.
Rails 5.1 introduced certain changes in the way a record is touched when
the counter cache option is enabled in a belongs to association.
We need to upgrade acts-as-taggable-on so it keeps changing the
`updated_at` attribute when a new tag is added to a record.
Note we now need to reload the records in some cases to get the
`context_tag_list` method to return what we expect. Methods like
`context_tags` however work properly with no need to reload the record.
Rails 5.1 doesn't align the columns in the schema file anymore, so
there aren't unrelated changes when we add or remove columns to a table:
https://github.com/rails/rails/pull/25675
We're sorry for developers who are really concerned about code
alignment.
Globalize does not support having translatable columns with the same
name in the original table and the translations table. We were planning
to migrate to Mobility, but we aren't doing so before releasing version
1.1.
We've also found a gotcha regarding having both columns: if we use the
`update_column` method, which we use in rake tasks to speed up the
process and in tests where we want to skip validations and callbacks, we
update the column in the original table and no exception is raised. If
we remove the column in the original table, we get an exception, which
is what we want since our intention is to update the column in the
translations table.
With this change we're following the advice given by the Mobility lead
developer: "If you don't need the columns, I think it would make sense
to just remove them to avoid any edge case issues."
This commit reverts commit 251326ea.
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.
Our manual implementation had a few issues. In particular, it didn't
track changes related to associations, which became more of an issue
when we made investments translatable.
Using audited gives us more functionality while at the same time
simplifies our code. However, it adds one more external dependency to
our project.
The reason for choosing audited over paper trail is audited seems to
make it easier to handle associations.
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.
Tags and help links can be edited, but aren't used anywhere. Since we
don't know what the intended behavior was, I'm removing them for now.
My best guess is tags were supposed to be used so investments for a
budget can only be assigned tags present in the budget. Achieving that
behavior wouldn't be a trivial task.
Unfortunately this feature wasn't properly reviewed and tested, and it
had many bugs, some of them critical and hard to fix, like validations
being skipped in concurrent requests.
So we're removing it before releasing version 1.1. We might add it back
in the future if we manage to solve the critical issues.
This commit reverts commit 836f9ba7.
We were converting markdown to HTML every time we saved a record, which
has the same problems as sanitizing HTML before saving it to the
database, particularly because the body of a legislation draft is stored
in a translations table.
Performance-wise this isn't a problem: converting a text with more than
200_000 characters takes about a milisecond on my machine.
Note we need to modify a migration generated by globalize, since the
method `create_translation_table!` would fail now that we don't define
`translates :body_html` in the model.
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.
We forgot to add these changes to pull requests which were in
development before we upgraded to Rails 5.
We're also moving the rubocop rules to the basic files, so we're
notified when we inherit from `ActiveRecord::Base`.
- Add :date_of_birth and :postal_code to Signature to allow send these
fields to CustomCensusAPI
- Add new model presence validates: Only validate :date_of_birth and
:postal_code presence when the application has configured Remote Census
and their alias fields has values.
This new functionality will allow to retrieve in the signature sheet
the document number, the date of birth and the postal code.
So we renamed :document_numbers to :required_fields_to_veriry to
clarify and adjust the name to its use.
We removed these columns from their original tables as Globalize raises a warning when making queries on the corresponding translated columns.
Since then we have decided to migrate from Globalize to Mobility, which does not raise these warnings.
We are still concerned about possible inconsistencies in the database due to maintaining these columns. However until we clear the problems out with the Mobility support team we are bringing them back.
- Each RemoteTranslation is associated with a resource (through polymorphic)
and has the locale to we want translate.
- After create a RemoteTranslation we create a enqueue_remote_translation
method that will be send remote translation instance to remote translation
client
To avoid deprecation warning thrown by Globalize after gem update. We
are going to keep these attributes with different names until next
release when we will be able to destroy them.
Also fix sort_by_title method [1]
[1] Use ruby sort instead of active record order scope because Globalize
does not provide a way to search over all available fallbacks when
translation for current locale does not exist.
After adding new translations to proposal we no longer need this
attributes in proposals database table, but we keep them with a
deprecated name until next release where we drop them completely.
Also related column indexes where dropped.
Adapt retire form to include needed translations and move validations
from controller to model.
Also change sanitizable concern to sanitize not marked for destruction
translations.
Some fields from Budget::Phase are translatable and we no longer need them. This commit will remove the annoying deprecation warning thrown by Globalize gem after gem version update.
Some fields from Budget::Heading are translatable and we no longer need them. This commit will remove the annoying deprecation warning thrown by Globalize gem after gem version update.
Some fields from Budget::Group are translatable and we no longer need them. This commit will remove the annoying deprecation warning thrown by Globalize gem after gem version update.
Some fields from Budget are translatable and we no longer need them. This commit will remove the annoying deprecation warning thrown by Globalize gem after gem version update.
Some fields from Widget::Card are translatable and we no longer need
them. This commit will remove the annoying deprecation warning thrown
by Globalize gem after gem version update.
Some fields from SiteCustomization::page are translatable and we no
longer need them. This commit will remove the annoying deprecation
warning thrown by Globalize gem after gem version update.
Some fields from Legislation::Question::Option are translatable and we
no longer need them. This commit will remove the annoying deprecation
warning thrown by Globalize gem after gem version update.
Some fields from Legislation::Question are translatable and we no
longer need them. This commit will remove the annoying deprecation
warning thrown by Globalize gem after gem version update.
Some fields from Legislation::Process are translatable and we no longer
need them. This commit will remove the annoying deprecation warning
thrown by Globalize gem after gem version update.
Some fields from LegislationDraftVersion are translatable and we no
longer need them. This commit will remove the annoying deprecation
warning thrown by Globalize gem after gem version update.
Some fields from Milestone are translatable and we no longer need them.
This commit will remove the annoying deprecation warning thrown by
Globalize gem after gem version update.
Some fields from AdminNotification are translatable and we no longer
need them. This commit will remove the annoying deprecation warning
thrown by Globalize gem after gem version update.
