When creating a form there is now a post category question, although
it's only compulsory for visitor forms. However even if it is not filled
because the question has a default value representing "no data" we ended
up storing that value in the database, and the default value is an
invalid post category for our database schema. This didn't seem to do
any real harm (Hotwire simply displayed a blank) but was at best confusing when
examining the underlying column data. This change checks for the default
"no data" value and sets the database column null in that case instead.

This broke when the changes to form generation around visitor types
were made - the bulk registration form needs to be passed the list of
types of visitor in order to do validation. Otherwise validation always
fails, even if not registering a visitor.

RT 230380: we want it to be compulsory for starters to have a photograph
taken and also get them to book an appointment for that via a third party
site. This updates the wording on the navigation page to point people to
the appointment system and tries to make it clear that having the
photograph isn't optional. Later on we will put something in place to
enforce that.

Slightly clearer wording I hope. Don't override the AllVisitors
home_institution question with the generic version, as that would undo
the effect of de3d5136 .

This is now set at form generation time.

The form generation form now asks for a post category when generating a
visitor form. This change ensures that data gets saved to the database.

As well as enforcing that a visitor type is selected for visitor forms
we want to enforce that it is not selected for other forms.

This adds validation to the form generation page's question about what
type a visitor is. If a visitor form is selected then the visitor type
question has to have a non-null answer selected.

This template was becoming difficult to read so has now been indented.

We want to have the person generating a form choose the type of visitor
when generating a form for a visitor, because our starters often pick an
incorrect type. This adds the question to the form and some styling to
make the whole thing more readable.

Nothing is done with the question data as yet, nor is there any checking
that a type is selected when a visitor form is generated.

The database module has a get_hids() function that generates a list of
2-element lists representing a list of foreign key values and their
human-readable equivalents from the database. These are used to present
select lists for post categories, nationalities and the like. Generally
the keys are integers. The function has an option to add a "null" option
to the list, for use in selects where input is optional. The value
associated with that defaulted to the integer -1.

This became a problem when I needed to add a select field with string
keys (post category ids) and also having a null option, because the null
option was coerced from an int to a string like the rest of the data, so
always failed validation.  This change makes the value for the null
option configurable but defaulting to -1.

We wanted the question about 'home address' to read 'Cambridge home
address' in order to prevent visitors staying in Cambridge for the short
term from putting their permanent home address down instead of where
they are staying day to day, but for many non-visitor categories this
makes no sense - it's possible to be staff living in Ely or Haverhill
and working here.

This change moves the special wording to only apply to visitor
categories.

b52c1067 defined the category of
embedded company staff as being separate from visitors, but didn't
implement the class providing the personal data form for them. This
change fixes that.

Present 'visitor' category last, as it's the catchall. Better help text
for embedded company staff.

Add separate form, w/o post cagetory or home institution questions.

Need to supply database view registration.embedded_company_staff_hid .

Need to update registration.visitor_hid to not include embedded company
staff, and to include a Visitor (Other) category, but that be done after the
separate form for embedded staff goes live. Need to check with Safety
what training Other should do.

None of this tested.

Improvements to visitor form

See merge request !7

Home institution question reworded and made compulsory - we need good
answers to this for visa checks and too many people leave it blank.
The rewording is necessary to help out people who aren't simply visiting
from another university to know how to answer it.

Home address question reworded to make it clearer it's the Cambridge
address we need.

RT 230000

We've been getting cases lately where people have been putting down
postdocs as their supervisor rather than the head of their group. This
causes problems because when the person gets imported into the database
they get no research group membership.

This change expands the question to help people pick the right option.
It also tweaks the CSS in order to make the longer question display
nicely, because the overflow settings we need for Chosen fields cause
the text to overhang onto the next question. Specifically we add clear:
both to the div that encloses each whole question and split the padding
evenly between the top and bottom rather than having it all at the
bottom. Then the text overhangs but doesn't push the question below to
the right, and we still get a bit of space before the next question.

Function added in 8ca86794 needs a test.

The name test_utils was too generic - this file only tested the utils.safety code.

This sets up the main form generation form to pick a default form type
dynamically when rendering the form. If there is more than one form type
available to the person generating the form no default is returned,
forcing them to actively select one. But if they only have one type
available to them that type is set as the default to save them a click.
This was motivated by the need to allow embedded companies to generate
registration forms for their staff, but they should only be allowed to
generate 'visitor' forms. It therefore makes no sense to make them click
to pick that option.

The safety handbook being missing is normal in a test instance of the
code, but the error message it produces makes it sound as if it's not.
This change tweaks the error message to make it clearer that the missing
handbook is a per-instance problem, and deploying the code as-is won't
necessarily lead to a missing handbook in production

Previously all people allowed to generate registration forms were
allowed to generate any type of form. We now need to allow embedded
company employees who don't hold a parallel post in the Department of
Chemistry to generate registration forms for their staff. Those people will
always be classed as visitors to Chemistry, so we should only allow the
generation of visitor forms. The code already implements this as it
queries the database to find out what form types are available to the
person generating forms and only offers those types. However the help
text for visitor forms didn't make sense when visitor forms are the only
option presented as it referred to 'previous' options. This alters it to
work better as a standalone option.

This now matches the updated safety questions from
af249ca0 .

RT 228354 - the numbering of sections in the Safety Handbook has
changed, making the references in the form inaccurate. Safety have
requested we do not give specific section numbers on the safety
checklist so this change removes them.

Strip whitespace from string fields in personal data form

Closes #74

See merge request !6

There were some other forms beside the personal data form that used
StringField where StrippedStringField would be more appropriate as we
don't want whitespace around the value.

We do not want people entering data with whitespace on the start or end.
This adds a subclass of StringField that adds a filter to strip its
input, and uses that subclass to generate form fields.

By execing python3 rather than running it as a child of /bin/sh shutdown
becomes a lot faster because then the SIGTERM gets seen by the python
process; when /bin/sh is the CMD and is signalled it doesn't pass the
signal on to its child python process, and Docker then waits for 10
seconds before sending a SIGKILL.

The live app has been migrated to Focal and Bionic is about to go end of
life.

It turns out to be necessary to mock out the whole of smtplib.SMTP
rather than just its send_message method, as otherwise an attempt to
open a socket when instantiating an instance fails when the test is run
from our gitlab setup.

Code should have tests.

Makes working on this on a machine with a package of chemistry_starters
installed easier.

New functions should have tests.

Added __init__.py to the tests directory to help with relative imports.

- adds a function in the database module to look up email addresses
for currently registered people and uses it to simplify
chemistry_starters.utils.mail_safety_induction_signoff

- completely remove
chemistry_starters.safety.get_safety_induction_signer as it can be done
with database.get_form_column

- update tests

Requested in RT 226948 where we were asked to inform the form creator
when the personal details and safety checklist had both been completed.

It seems unlikely that a single email at this point in the process is
really all that is wanted, so this change adds a new function to send an
email with a progress report to the form creator, and calls that when
the safety form is submitted. If we're asked to send emails at other
stages too we can just call that function again.

It also adds a function to get the email address of a currentty
registered person from their database id. This can be reused elsewhere.