For the HashAlignment rule, we're using the default `key` style (keys
are aligned and values aren't) instead of the `table` style (both keys
and values are aligned) because, even if we used both in the
application, we used the `key` style a lot more. Furthermore, the
`table` style looks strange in places where there are both very long and
very short keys and sometimes we weren't even consistent with the
`table` style, aligning some keys without aligning other keys.
Ideally we could align hashes to "either key or table", so developers
can decide whether keeping the symmetry of the code is worth it in a
case-per-case basis, but Rubocop doesn't allow this option.
Currently with both seeds and dev_seeds, not only was this email not
displayed from the system emails section, but it also caused an error in
the application.
@email_to had an empty value and in the view we tried to access
@email_to.name which caused the error. We kept the same logic but
added the current_user to make sure it always has a valid value. We add
the current_user because the current_user is always present in this controller..
Since PostgreSQL doesn't guarantee the order of the records unless an
`ORDER BY` clause is used, the records sometimes had a different order.
This might cause records being present in more than one page.
One test was failing sometimes (when the record created first was
rendered after the record created last) because there seems to be a bug
in chrome/chromedriver 83 and later which causes links not to be clicked
when they're right at the edge of the screen (which was the case for the
notification appearing in the last place):
```
1) System Emails Preview Pending #moderate_pending
Failure/Error: click_on "Moderate notification send"
Selenium::WebDriver::Error::ElementNotInteractableError:
element not interactable: element has zero size
(Session info: headless chrome=91.0.4472.114)
```
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
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.
