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.
If we validate the presence of the old value and the new value, changes
in optional fields will not be stored if either the old value or the new
value are blank.
Usually when we specify a `belongs_to` relations, we also specify its
equivalent `has_many`. That allows us to write, for example:
`topic.user.topics`.
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
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`.
Generalize the BudgetInvestmentStatus model to Milestone::Status so it
is not specific to budget investments, but can be used for any entity
which has milestones. This is in preparation to make the Milestone
model polymorphic and usable by entities other than budget investments.
Using `Date.today` caused some milestones to be published before/after
the date defined by `Rails.application.config.time_zone`.
See also commit AyuntamientoMadird/consul@088c76d for a more detailed
explanation.
Note the title field was hidden since commit 01b9aa8, even though it was
required and translatable. I've removed the required validation rule,
since it doesn't seem to make much sense and made the translatable
tests harder to write.
Also note the method `I18n.localize`, which is used to set the
milestone's title, uses `I18n.locale` even if it's inside a
`Globalize.with_locale` block, and so the same format is generated for
every locale.
It turns out it is not necessary to downcase and underscore
locale names to use the globalize-accessor gem. The gem
will automatically underscore the locale name when defining and
calling the accessor methods.
There was a problem with the portuguese locale.
The locale was pt-BR, but `globalize_accessors` gem
doesn't allow the creation of methods using locales
with that format.
To avoid transforming pt-BR to pt and lose the distinction
of the different variations of the language, a function has
been added to transform pt-BR into pt_br (without changing
the locale itself). That way, when globalize uses the locales,
all of them will have a valid format (downcased and underscored)
AND they will be always the same (comparing pt-BR with pt_br
doesn't work).
The csv generation doesn't seem like a Model concern, at least not taking
into account the amount of lines of the method (36+). Just a simple ruby
class that encapsulates the logic makes it easier to read and maintain as
we increase the columns exported.. also customize in case other forks need
different values.
Add fields to the milestone form so that the admin can attach 0, 1 or multiple documents.
Add column to milestone list with a link to documents (if there is any).
Make documents accessible from the milestone view for users.
