GitLab

Fixes: bf105472

We just ran in a regression, because pre-merge testing could not be
used to test the creation of the container. So let's fix that!

I don't like the current solution, but we'll revisit it later as part
of a potential conversion to CI templates.

With this change, we add an `end` field to the MembershipPeriod class,
to be able to say when members of the previous period will stop
receiving new emails.

Closes: #41

Validation already exists to prevent that, but this makes it easier
for users to rank the different options, without fearing giving more
points to one option.

Closes: #38

Closes: #28

Rather than creating a new function every time we add stuff, just
create one to rule them all.

Having links that you cannot click are confusing, and expecting users
to see the "Thanks for voting!" text added to the title of the link
was pretty bad.

Instead, this commit adds "(voted)" on the side, and removes the href
on the link, which leaves the decription open, but hides the clicking
cursor.

Suggested-by: Emil Velikov
Closes: #37

The new solution isn't particularly pretty either, but it is less confusing.

Drop testing on python 3.5, as it is unsupported by django 3.0

We limit ourselves to django 2.2.19 for now, as django 3.0 regresses
some tests.

Closes: #42

As per section 2.5 of the X.Org Bylaws, members have affiliations,
not employers. This commit fixes this oversight!

Reported-by: Pekka Paalanen
Closes: #39

This works without them as long as the string is 1 character-long...
which is why the unit test was fine with it!

Upon parsing the result coming from the user, we convert the DB ids
we sent to the user into actual DB-backed python objects.
Unfortunately, the _get_objects() helper that performs this conversion
did not return the objects in the order the user ranked them, but
instead the order in which the objects had been created in the DB...

Not only was this oversight was then not caught by unit testing,
because test_valid_form() was concentrating on verifying that we were
getting the right objects rather than checking the order, but this also
escaped our multiple mock election attempts... I guess humans like to
rank people based on the number next to them...

The fix is simple, albeit inefficient: make one query per option, in
the order the user gave us the list. On the unit test side, multiple
combinations of ranks are now tested to prevent such regressions to
ever happen again. Finally, for the new manual validation plan, the
idea will be to use a theme and make sure people will not all order
things in different way.

Appologies for the mess this caused...

Closes #32

Closes #18.

Good that it got caught by gitlab's CI!

Fixes: 818e65b1

Closes #19.

Closes #29.

This implements part of #23.

No idea why I could not manage to use them before...

Closes #24.

This was the defautl behaviour, I should have kept it!

This simplifies deployment.