Settings are stored in the database, and so any changes to the settings
done during the tests are automatically rolled back between one test and
the next one.
There were also a few places where we weren't using an `after` block but
changing the setting at the end of the test.
By default we want this attribute to be the current heading id for existing investments. If there have been reclassifications, this field should be updated accordingly.
The `type: :feature` is automatically detected by RSpec because these
tests are inside the `spec/features` folder. Using `feature` re-adds a
`type: :feature` to these files, which will result in a conflict when we
upgrade to Rails 5.1's system tests.
Because of this change, we also need to change `background` to `before`
or else these tests will fail.
After run the rake to move external_url to description for Proposals and Legislation proposals this spec is failing because external_url field doesn't exists anymore.
This spec is giving some problems related to duplicity of records due to the way rake tasks are loaded.
It will soon become part of seeds anyways. Removing for now.
These tasks dealt with data migrations or stats generations which were
done only once, so we don't need them anymore.
New CONSUL installations don't need these tasks, and existing CONSUL
installations will execute them when upgrading one release at a time.
Execute rake task every day to detect new actions available for not archived proposals. If there are new actions available for today, send email to proposal's author with information text, new actions available and link to proposal dashboard url.
From now on these static pages:
`/privacy'
`/conditions'
`/accesibility'
`/help/faq'
`/welcome'
have been moved to the DB and can be modified easily by any
administrator in `/admin/site_customization/pages'
When we insert a record in PostgreSQL and we specify the ID, the
internal ID sequence for that table isn't updated.
In order to keep the original IDs so we didn't break any foreign keys,
we specified the IDs when copying the table, resulting in a table having
its ID sequence with a value of an existing record. When trying to
insert a new record, we got a `PG::UniqueViolation` exception.
Updating the sequence after the data migration might not be the most
elegant solution, but it's easy to do and it's already been tested on a
production environment.
Calling `load_tasks` in several files made rails load the tasks several
times, and so they were executed several times when called.
Since the milestone migration can't be executed twice in a row (it would
fail with duplicated ID records), loading the tasks several times made
the milestone migrations task specs fail.
Ruby can't have hyphens in method names, so sending something like
`record.title_pt-BR` would raise an exception.
Using globalize's `localized_attr_name_for` method fixes the bug.
Thanks Marko for the tip.
We think aborting the migration will generate more headaches to system
administrators, who will have to manually check and fix every invalid
record before anything can be migrated.
The db:dev_seed rake logs info as it progresses as information for the
developer. But that's not needed when ran from its tests file, and it
bloats the travis/rspec output with unnecessary information.
Now the task will always log info unless the rake task receives an
optional argument.
This cop tries to avoid state leaking between examples. The fixes done on the code don't follow the suggested path, since the usage of `before(:all)` was not really useful. By using RSpec's `let` method we achieve same goals but with much better and readable tests.
Check Cop description at http://www.rubydoc.info/gems/rubocop-rspec/RuboCop/Cop/RSpec/BeforeAfterAll
