To make it more consistent with the rest of the Admin panel,
the CRUD for budget groups and headings has been changed
from the old "all-in-one" form to a separate form for each resource.
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.
The `update` action is usually expected to behave the same way it does
everywhere else, which is updating a record using the `params` hash.
The name `toggle_select` comes from the name we use in a similar
situation for budget investments.
In the admin section of the application, a new page
has been added so that the admins are able to manage
the selected texts for translate.
The texts have been divided in different "sections",
depending on the nature of themselves (budgets, polls,
proposals, management, etc.). Each section has become a tab
with a form associated to edit all the texts for her.
When a language is added, it's added for ALL the texts in the
application. That means that, if an admin adds french for debates,
the french form will appear for the rest of the texts. That doesn't
mean that they need to fill all the texts, only that the languages
work for all of them instead of individually.
Some system emails need to be manually reviewed before being sent. This
new action allows admins to see a preview of all Pending to be sent
Proposal Notification Digest messages.
Admins need to be able to see what a particular System Email looks like
with dummy data.
Also adding the first system email to be managed: the proposal
notification digest.
In case the current admin doesn't have any Notifications from
ProposalNotifications there will be a crash. We'll solve this in later
PR's with a system to "inject" sample text in email templates without
having to generate records in the database.
In the same fashion Newsletters is managed, with the only difference that
the preview is using the notification partial in the same way the index
of notifications.
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.
The back button when the user changes the password
(in the print password page) redirects to the
edit manually page.
The routes to access password edit pages has been added,
along with the ones to send reset password email and
reset password manually.
Running test suite the following appears: DEPRECATION WARNING: Defining
a route where `to` is a symbol is deprecated. Please change
`to: :json_data` to `action: :json_data`.
