| Age | Commit message (Collapse) | Author |
|---|
|
Otherwise everyone can just access any profile.
|
|
We copied the factory method from Track, but forgot to change some of
the words. Now the code fits better with what the function is doing.
As a bonus, pylint no longer complains about a duplicate method.
|
|
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.
|
|
|
|
Otherwise it'll show progress bars.
|
|
|
|
|
|
This would otherwise happen if e.g. the user has the page open, the
SQLite file is deleted, the user then activates the overlay layer, and
the sqlite3.connect() creates the database.
|
|
|
|
|
|
|
|
|
|
The reason for that is that we want to add "longest track"/"shortest
track" soon, and the profile() function is getting a bit long
|
|
This makes it a bit easier to generate heatmaps, but at the moment, it
only works manually.
The "long-term" goal is to have fietscron generate heatmaps on a regular
basis.
|
|
With the previous logic, we only counted those that the user themselves
uploaded.
|
|
|
|
|
|
Otherwise it does look very empty when you open the page.
|
|
|
|
So far, fietsboek does not generate them, but if you happen (by
accident) to have hittekaart output a heatmap to the right location, the
profile page will now show it.
|
|
|
|
This is not really a profile page, but rather a page to change your
personal data, so it should be named accordingly (in preparation for
real profiles).
Additionally, we use POST requests to deal with the data change.
|
|
Turns out you need to supply an actual empty array.
While we're playing with the CI configuration, we also move the
deprecated global image/cache/before_script sections into the "default"
section.
|
|
|
|
|
|
Yay, types! (And a lot of escape hatches)
|
|
This makes it consistent with the other scripts (fietsupdate,
fietscron), and makes the argument parsing setup a bit nicer to read.
|
|
|
|
|
|
I'm not the biggest fan of combining many package managers, but the
JavaScript libraries (Bootstrap, Bootstrap-Icons, later the @types
modules and Leaflet) are easy to get via npm, so maybe we can use that
to our advantage and have npm at least download them.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
This helps if the upload/editing process fails, so that we don't end up
with orphan data directories (probably the most important change!), or
superfluous image files.
|
|
Getting ready for SQLAlchemy 2.0!
|
|
|
|
|
|
For some reason, I have GPX tracks that have the first two points be
~100 meters apart in elevation, but only ~20 meters apart in distance.
This is quite unrealistic and produces pretty bad height plots (almost
as bad as the zero elevation).
Since the issue is very related, and the fix is pretty much the same, I
thought it would be a good idea to adapt the FixNullElevation
transformer to handle this case as well. For reference, "the internet"
says that the maximum slope for a MTB is ~15% to ~35%, depending on the
conditions - with 35% being pretty steep. I think it's fair to throw
away elevations that exceed 100% (basically a 45° angle upwards),
especially since we only discard them at the start and end.
|
|
|
