Public view for suggested actions as well as resources has been
completelly redesigned.
Private side for this feature has been adapted as well in order to meet
the requirements.
New group created in administration menu including dashboard resources/
proposed tasks and pending tasks for the administrator.
Some unused files have been removed.
* Delete all things related to banner images and styles (in code)
* Add a new test to check that the banner is showing correctly
* Update the specs accordingly to match the changes
Update dev_seed to set a random background_color and a font_color for banners (and remove everything about image and style)
Add a rake task to migrate the banner style to backgroun_color and font_color (so that the banners have the same colors than before)
Banner sections can be saved (one banner can appear in several sections)
If the hex color is changed in the textfield, the color of the color picker changes.
Add new routes for the proposal notifications edition and
abilities to let moderators edit it (mark as ignored, hide, etc.).
The notifications are not flaggable because they doesn't work like that,
but in a similar way. The moderator/administrator is in charge of hidding
them through the UI, so the normal users don't flag it as inappropriate.
New controller Moderation::ProposalNotification to manage the moderators
work.
Note there is some funkiness going on with class loadings
Had to create a `feed` and `widget_feed` table even though in this
first version the Widget::Feed includes only uses ActiveModel instead
of ActiveRecord, otherwise some specs failed
We’ll figure it out and clean up 😌
- Cleanup Translatable module (`translation_params` method too large)
- Move globalize_helpers partial to admin folder
- Use any class for method translation_params
- Helpers in `GlobalizeHelpers` make sure all are in use and see if they can be more legible
- Review js name clases and methods see if they can be more legible
- Refactor milestone views into partials with nice spacing between attributes
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.
