| Age | Commit message (Collapse) | Author |
|---|
|
It was ovious that this is broken when you try to round "0s" to
second-level granularity, and you end up with "1s". The problem comes
from the fact that we use the integer divison when checking whether we
should round up or down, but then also use strict inequality.
To fix this, we now also round down if the second_offset is equal to the
halfway point (which in the case of second-level granularity is 0).
|
|
We basically do the same hacky trick in two different places, so maybe
we should put it into a separate function, test it, and if a better
implementation arises, swap it.
|
|
Currently, the test seems flaky on CI due to
playwright._impl._api_types.Error: Clicking the checkbox did not
change its state
Maybe this is the change that will fix it?
|
|
This gets the intent across clearer
|
|
|
|
|
|
While it shouldn't change the outcome of the test, it might make the
test less flaky, as the expect call will wait until the page is loaded -
which also indicates that the data is updated. Without this, the test
depends on the backend being "fast enough" with applying the
transformation.
|
|
|
|
Getting ready for SQLAlchemy 2.0!
|
|
|
|
|
|
|
|
|
|
This is code that needs to be repeated in possibly several places
(website, API, tests), so it makes sense to have those "high level
actions" a bit abstracted. edit.edit_images was already doing that to a
certain degree, but the code shouldn't have stayed in the view.
|
|
|
|
|
|
To add more playwright tests and to cut down on the duplicated code, the
helper methods have been put into a small class. This way, we don't have
to add 100 pytest fixtures.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Now that the filtering is done via SQL, it is not enough for the user
and the objects to be in the session - they need to be in the database,
similar to the added tracks.
Note that it was not entirely necessary in this case, since the tracks
are public, but it provides the proper functionality in the future.
|
|
|
|
|
|
|
|
|
|
|
|
It turns out that the mt:TourStartTime is also given in UTC, and
therefore cannot be used to get the timezone offset. The problem was
that my local computer's timezone was the same as the tour timezone, so
by the magic of Python's datetime.datetime.fromtimestamp (and the date
CLI util), I did not notice that the timestamp actually represents UTC.
Sadly, it currently looks like there is no way to extract the time zone
from a MyTourbook export.
|
|
|
|
|
|
|
|
|
|
|
