Fixes salsa issue 46 (not putting the hashtag otherwise I fear the BTS
will explode)

Signed-off-by: Mattia Rizzolo <mattia@debian.org>

urbec authored May 25, 2021 and Pierre-Elliott Bécue committed May 25, 2021

Signed-off-by: Pierre-Elliott Bécue <becue@crans.org>

This is not simply fixing up spelling and grammar, but a full (ish)
review of English language strings and translation structure. This lays
the groundwork for a more formal translation round at a later date.

Some of the phrasing will inevitably be coloured by en_GB preference,
but I don't feel any shame about that.

To avoid FD approval to be challenged if a DD has a doubt, comments on
an approval requirement will block the RT ticket sending until either
the FD/another FD adds a new statement or DAM adds a statement.

Signed-off-by: Mattia Rizzolo <mattia@debian.org>

Signed-off-by: Mattia Rizzolo <mattia@debian.org>

Now, the "Approve (old)" button is replaced by a "Approve (No RT)"
button, useful to reapprove an unapproved process without changing
anything else

The "Approve provess" button is a redirection to the
"approval/statement/create/" page, and the "approve" url is deactivated.

Signed-off-by: Mattia Rizzolo <mattia@debian.org>

process: set the default audit_notes in ProcessRT differently, so that it can better values can be passed to it

Signed-off-by: Mattia Rizzolo <mattia@debian.org>

This is obviously an error which the server did met.

Approval becomes a Requirement of a process. When this requirement is
fulfilled, it makes the process become approved, whatever the state of
the other requirements.

Depending on the status of the approver, the StatementCreate view either
spawns a ProcessApproveRT op to send immediately a RT ticket, or just
spawns a ProcessApprove op, to approve the process.

The approval statement contains the RT ticket that is sent or not. In
the case it's not, a housekeeping job could iterate through the
processes on a regular basis and as soon as the approval requirement is
old enough, spawn a RT ticket using the approval statement.

To avoid issues with testing instances, the ProcessApproveRT has been
reworked in order for the RT part to be mocked, returning 0
systematically.

Allow everyone to download signed statements as a mailbox, but filter contents as appropriate. refs: #6

I.e., we shouldn't warn if the applicant is one of:
 * dm/dm_ga
 * dd_nu
 * dd_e/dd_r
Given that the reverse set of the above just leaves out dc/dc_ga, just
check for that.

Thanks: urbec for noticying it in a dd_nu → dd_u case.
Signed-off-by: Mattia Rizzolo <mattia@debian.org>