While we were creating development seeds with map
locations in Madrid the default map coordinates were
placed in Greenwich. Now when we run the
`dev_seed` task we'll have the default map coordinates
and the sample data placed in Madrid.
When we create a budget heading through factories it's placed at Puerta del Sol,
Madrid. It seems reasonable that the `map_location` factory places the points near
there.
Before these changes sometimes the map center was placed in Madrid while map
locations were placed in Greenwich, therefore markers were not visible in the
map current pane.
Before this change, two important things depend on the format of each key,
where to render it in the administration panel and which kind of interface
to use for each setting. Following this strategy led us to a very complex
code, very difficult to maintain or modify. So, we do not want to depend
on the setting key structure anymore to decide how or where to render each
setting.
With this commit, we get rid of the key format-based rules. Now we render
each setting explicitly passing to it the type and the tab where it belongs.
Instead of using a setting nested param `setting[:tab]`. We only need
the tab param when rendering settings in the administration section.
This change will make it easier rendering the correct tab after
updating settings.
We moved the "Custom content blocks" menu entry from "Settings" to "Site
content" in commit a902f9e11, but we forgot to update a description
referencing the old location..
This way it won't be possible to browse all user URLs by just going to
/users/1, /users/2, /users/3, ... and collect usernames, which might not
be desirable in some cases.
Note we could use the username as a URL parameter and just find the user
with `@user = User.find_by!(id: id, username: username)`, but since
usernames might contain strange characters, this might lead to
strange/ugly URLs.
Finally, note we're using `username.to_s` in order to cover the case
where the username is `nil` (as is the case with erased users).
This way only verified users will be able to access this page, which
shows the username of the receiver of the direct message. With this,
it's no longer possible for unverified users to browse direct message
URLs in order to collect usernames from every user.
This will allow us to keep using the timezone used when running
the installer.
We keep using Madrid as default timezone in the installer and in
the application.
As Rails does with the application log and other tools. We
are going to use the same filtering rules we use in Consul Democracy.
We are renaming the initializer file name `filter_parameter_logging.rb` so
it's loaded before the errbit initializer.
As this secret is currently not programmed to be customisable for each Tenant,
we take it out of the security section. The reason is that so far everything inside this security section can be overwritten per tenant. With this change we are trying
to prevent anyone from trying to overwrite it on a per Tenant basis, as it would have
no effect.
In order to test that we remove metadata from PDF we need add
"pdf-reader" gem.
With this gem we can check the info from the PDF and ensure that
this info is removed.
In order to remove metadata from PDF documents we will use the
exiftool_vendored gem.
The following line:
Exiftool.new(attachment_path, "-overwrite_original -all:all=")
Overwrites the original file with another file without metadata.
So far this is the best solution we have found to perform this
metadata deletion.
When using Exiftool an exception is thrown, so we added a rescue
to handle it. Here is a task created where this problem is discussed
in issue 28 in the https://github.com/exiftool-rb/exiftool.rb/ repository.
We'll wait to see if this will be fixed in future versions.
