| Age | Commit message (Collapse) | Author |
|---|
|
Since we changed the logic to support image descriptions, we need to
adapt it here as well. Without this fix, images would only be uploaded
from the "edit track" view.
|
|
|
|
|
|
This now works if there is really no date given in the GPX file, as done
for example by the files produced by BRouter.
|
|
Some tracks (especially the "premade" ones) lack the time and speed
information. We just assume some random values in those cases, which is
better than crashing the site. In the future, this is gonna be important
once we implement "template tracks".
|
|
|
|
|
|
|
|
|
|
|
|
Previously, pressing enter in those text boxes triggered the form to be
submitted. This was rather unintuitive, therefore Enter now triggers the
correct action (add a tag or search for friends).
|
|
We cannot add them to image files, because FileResponse may use the wsgi
provided file sending mechanism right when the object is created.
FileResponse does however use the Last-Modified header, which is also
okay.
|
|
|
|
Depending on the Python version, this might raise an error: Before 3.8,
mimetypes.guess_type could not deal with a pathlib.Path, and only
accepted a string. guess_type is called internally by FileResponse, so
to make sure we don't run into errors, we stringify the path before
passing it to FileResponse.
|
|
|
|
|
|
|
|
Even though the change is "relatively simple", it does add quite a bit
of stuff since now we do need metadata in the database.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is just debug logging information, but accessing self.id for an
object that is not in the database raises an error, because self.id is
None and %d cannot format None. In this case, we simply use -1 as id
instead.
|
|
|
|
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.
|
