GitLab

The old technique was horribly out-dated, and no longer worked on my
machine,
following an OS upgrade.

Tagging this as release 1.1.2.

Specifically, this affects the python client, making it use the latest
available TLS version supported by both the client and the server.

Currently, the server supports TLS 1.0, 1.1, 1.2 and 1.3 (and no SSL
versions).

This code was originally copied from the Ibis client library which,
when it was written, only supported SSLv3 and TLS 1.0 on the server,
so forcing TLS 1.0 made sense, but things have move on since then.

The historical data used in places in the self tests has changed, so
update those tests accordingly.

Also included the root certificates themselves, and all intermediate
certificates we have ever used, just for reference, and instructions
on how cacerts.txt is constructed (from the root certificates alone).

The new root certificate will be needed by the python and PHP clients
to allow them to connect to the UTBS when its certificates are
renewed, since they will be signed by a new root.

No change needed for Java clients, provided that they are running on
Java 8u91 or later, which ships with this new root certificate.

Also updated the Javadocs to build with Java 1.8.

Tagging this as release 1.1.1.

For API methods that require authentication, be more explicit about the
exact privileges required.

Additionally, in the PHP docs, increased the spacing above the HTTP
method and path that is automatically inserted at the bottom of each
method's docs.

There are 2 new methods. One to get all venues for a particular training
provider, and one to get all venues for all training providers.

There are 2 new methods. One to get all themes for a particular training
provider, and one to get all themes for all training providers.

Additionally:

* Consistently return themes in (title, ID) order across all API
methods.

* Tidy up the documentation for the fetch parameter, making it
consistent across all API methods.

* Fix the script to auto-generate python and PHP client code to account
for the fact that *all* parameters of a method may be optional.

All events returned by the API now return the maximum number of
participants on the events -- an integer (possibly null).

This consists of 3 new methods, one for each of the 3 groups of bookings
as they are presented in the web application -- current bookings,
registrations of interest and training history.

Also added a fetch parameter to the getPerson() method, to make it
consistent with all the other similar API methods. Even though there is
currently no fetchable data for people, one day there might be, so this
makes the API more easily extensible in the future.

These allow self-taught events to be retrieved for programmes, themes
and courses.

This returns programmes from all training providers, unlike the method
from the previous commit, which returns programmes from a single
training provider.

This includes some changes to the client code to support passing pure
dates as well as date-times as input parameters to API methods.

This now tests all the possible values of the fetch parameter, and did
reveal a bug (a typo) in the event -> related courses fetching code on
the server, as well as a bug/typo in the python client code to unflatten
a list of venues.

This allows bookings for multiple events to be retrieved in a single
request.

These don't test creating bookings or people, since there is currently
no way to automate that test, because the database cannot be restored to
its old state.

This will update an existing booking, and optionally create a new
booking if one doesn't already exist for the participant.

TODO: Unit tests for this new method.

This might be for people who should have booked, but just turned up
instead. Or it might be for open events that don't require booking,
where attendance is being recorded. Either way, a booking is required to
record the attendance, and none of the existing booking statuses is
really appropriate, hence this new status: "did not book".

This works across all training providers.

Its constructor now also accepts offsets in hours and/or minutes, and
the documentation now has a more complete python code example.

Also changed the matching method for events in a venue in a time period
so that the endpoints of the time period and the events are treated
inclusively rather than exclusively. This allows these methods to work
if the start and end of the time period are equal - i.e., to find any
events running at a specific instant in time.

All API methods will now automatically return unpublished events and
programmes if the user is authenticated and has the appropriate
privileges to view them. This should work for the entire API, including
for events and programmes fetched from other entities via the "fetch"
parameter.

This makes all the API methods consistent with respect to how they
explain what is returned by default and how the fetch parameter can be
used to return more.

This required some refactoring of the client infrastructure code to
better support date-time handling. The clients now pass dates to the
server as ISO 8601 formatted strings.

Make this getAllProviders() instead, for consistency with other API
method names.

This can either set the attendance for all sessions booked by the
participant, or for a specific session.

This also includes an extension to code to auto-generate PHP client
code, so that it can now handle Java Boolean and Integer data-types.

In passing, fix a bug in the PHP client connection class: this should
not include null form parameters in the data sent to the server, since a
null Integer would then be encoded as "" (an empty string), which the
server fails to parse.

These are translated directly from the Java unit tests.
They revealed one bug - just an annoying typo.

If nothing has changed, don't change any timestamps on the generated PHP
documentation, so that the doc tarball is unchanged.