| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This makes sure that the exit code is set properly
|
|
This does two things:
1. fietsupdate update --help works (before it errored because the
required argument is not given)
2. fietsupdate help works (like git help ...)
|
|
This moves the updater scripts into a subfolder, which keeps them
separated better from the rest of the package. In addition, we now have
the "fietsupdate" command instead of using "python -m
fietsboek.updater".
|
|
|
|
If we apply a migration that takes us from "v1" to "v2", then a
downgrade needs to apply the reverse of this migration - not the one
that goes from "v1" to "v0", and not "no migration".
The previous code managed to not do this, as it would see "v1-v2" as
applied and therefore skip it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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".
|
|
|
|
|
