| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
By not using an OUTER JOIN, we were missing the tracks that did not have
an associated track cache. The filters already deal with this case (by
having a IS NULL check), but we need to actually include those rows by
using an outer join here.
|
|
This is a continuation of the previous two commits, in which we do the
filtering in the SQL query instead of retrieving all objects and then
filtering them in Python.
The generated SQL can be quite complex, but
1) most of it comes from the logic of determining the visible tracks and
2) it is built piece-by-piece with small Python functions.
Therefore, it should be okay.
|
|
While this requires some logic duplication, and it does mean that we
have to generate complex SQL queries, it is also the preferred way of
doing this, as we do not have to load all the tracks just to filter them
out in the application.
|
|
The speedup is probably negligible, as a single user shouldn't have
enough tracks to really make a difference, but it is good practise to
let the SQL engine do the filtering and only retrieve the objects that
we actually need.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Since bootstrap-icons includes nice "person" icons, it is probably more
fitting to use those for the friendship actions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The usage of os.urandom was fine to generate a salt, but using secrets
here makes sure that the intent is carried across.
For the share tokens, using random might be insecure. We should err on
the side of caution and use a secure PRNG here, so now we use secrets
here as well.
For tokens (password reset, ...), UUID4 is probably also fine, so we'll
leave that for now.
|
|
|
|
|
|
|
|
It just looked odd on the actual website.
|
|
|
|
|
|
|
|
This will properly escape special characters and quotes in the string.
|
|
|
|
|
|
|
|
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.
|
