| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
This is used for the README and the CHANGELOG, as they are read during
setup.py. If we do not include them, building a source distribution will
fail.
|
|
|
|
This is for example useful for the template inputs. They should not be
sent due to the "disabled" attribute, but we never know what browsers
are doing, therefore we stay defensive. The test case already has to do
extra steps to prevent those from being sent.
|
|
|
|
A few lines above the change, we set track.date to a timezone-aware
date. We shouldn't overwrite it with a naive datetime right after.
|
|
The big button with the large padding looked kind of silly, so now the
button is slimmer and the text is actually centered.
|
|
|
|
|
|
|
|
|
|
For the most part, we want to know the instant of when something
happened. To stay consistent, we save everything as UTC. For internal
things, this doesn't really matter - we just need to know the timezone
to be able to compare the values (like "is the upload older than 5
days").
For user-facing things (like comments), we still want to store the UTC
time and then convert it to the user's preferred timezone on display.
|
|
|
|
|
|
After the change to pyramid contexts, this parameter is now track_id.
This was missed back then.
|
|
|
|
Sometimes, the GPX itself does not have a name set, but the single
tracks might have.
|
|
|
|
The other code kinda assumed that we can turn the resource path into a
package by replacing the slashes (path separators) with dots. That
turned out to not really work in the end, especially if the resource
subfolders don't have a __init__.py in there.
This uses the .files() API (available in Python 3.9 and backported in
importlib_resources) to better handle folders in the resources.
|
|
|
|
Those things are not really a configuration thing that changes, rather
they are part of how the code of the application works. As such, it
doesn't make too much sense to require those configuration values.
Instead, we now add those filters programatically.
This also ensures that the filters are the same between development,
production and testing environment.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This cuts down on the code duplication and makes sure that we use the
same algorithm everywhere. It also keeps the view code cleaner.
|
|
This puts the handling of retrieving the right database object at a
single place, which makes it easier to use from the different routes,
and unifies the error handling (some places for example lacked the check
to see if the returned object is None).
It is also the first step to a better permission system based on
Pyramid's ACLs, as we can now implement those on the object. This will
make the code even better and even more uniform, as we don't need to do
the permission checks manually anymore.
|
|
The main issue was this: Our body has a slightly lower font weight of
300, so "bolder" works out to be 400 - which is a barely noticable
increase. The reason for this is that "bolder" (and "lighter") are
relative font weights, but they only work relative to certain
"breakpoints" - and 300 was just a notch below the next breakpoint of
400 [1].
By setting the font-weight of "strong" to 700 directly, we get a
noticable boldness increase instead, though we might tone it down just a
notch in the future.
In order to prevent font issues in the future, we've now also included
all proper variants of OpenSans, so that all font styles are available
to us, using the webfonts helper tool [2].
[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight#meaning_of_relative_weights
[2]: https://google-webfonts-helper.herokuapp.com/fonts
|
|
This might need some fine tuning in the future
|
|
|
|
They shouldn't change that much (currently, there is not even a way to
change them from the web), and it saves a lot of data to cache the
megabytes of GPX data.
|
|
|
|
|
|
|
|
This prevents "weird" objects from lingering around. Now, if a user is
deleted, their tracks are also being deleted - which is good, especially
for the user's privacy.
For a more "graceful" closing of the account, we could implement a
strategy that first re-assigns the tracks to a different owner, and then
deletes the account. But that may only happen with the consent of the
user, and it is a work for future improvements.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This looks way better than doing wonky space-separated things.
|
