| Age | Commit message (Collapse) | Author |
|---|
|
Not efficient to send a request to the TomTom API every time we save a
Route, but I'm banking on developing a cache system soon to avoid having
to make the requests, so hopefully that will stop this from making
expensive remote calls all the time.
Refs #6095
|
|
This method wasn't indented to the same level as the rest of the file.
Refs #6095
|
|
This new method will launch a worker that takes the route's `StopArea`s,
converts them to `WayCost`s, sends them to the TomTom API to calculate
distance and time costs, and saves those costs to the route's `costs`
field.
Refs #6095
|
|
Refs #6095
|
|
Fix the journeys time editor. Refs #6036
|
|
Add detailed view for purchase windows. Refs #6042
|
|
|
|
And fix the way offsets are computed to use the timezones
|
|
Refs #5972
|
|
|
|
|
|
Refs #6187 Fix Dashboard Calendar#show link
|
|
|
|
|
|
|
|
5567 Disable routes by default
|
|
6068 simple exporter
|
|
|
|
|
|
|
|
|
|
With token-based authentication
|
|
Also added a *dumb* `WorkgroupExport` for testing purposes.
|
|
|
|
Still needs to be made asynchronous
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix compliance_check_resource and compliance_check_set status Refs #5…
|
|
|
|
Thanks to Johan for helping me with this. He correctly remarked that
what I had before will do an `INNER JOIN`, which ends up excluding lines
that don't have an associated company. I didn't really think about the
data, and didn't realise we had lines without a company.
Big thanks to Johan for seeing that I needed to add `public.` to qualify
the `companies` table in order for the join to work. Otherwise it
doesn't work correctly and we can't filter by company name.
Refs #5889
|
|
Johan made a number of good points here:
> * I think this belongs in the model
> * I would rather use a named parameter here
> `.where('lines.number LIKE :q OR lines.names LIKE :q ...', q: > "%#{params[:q]}%")`
> * You should defiitely escape the params before passing it to your db.
> `sanitize_sql_like` seems like the best choice here
I wasn't thinking about sanitisation at all and just assumed the `?`s in
the prepared statement would take care of it for me. But obviously,
we're passing `%`s in the param, so users can of course do the same
thing.
Protect against this using the
`ActiveRecord::Sanitization#sanitize_sql_like` method. This is a private
class method, so in order to use it we have to call it from inside the
`Chouette::Line` model.
And of course the named parameters are a no-brainer. At the time, I had
seen that `Array` splat somewhere else in the codebase and just blindly
copied the format, forgetting that named parameters even existed.
Refs #5889
|
|
Johan recommended not putting it in a separate `/autocomplete...` route,
but instead to use `/referentials/4/lines/autocomplete` to be more
RESTful. Makes perfect sense.
Refs #5889
|
|
This is no longer needed thanks to the `AutocompleteLinesController` and
the AJAX filter in
`app/views/referential_vehicle_journeys/_filters.html.slim`.
Refs #5889
|
|
Get rid of the heredoc to allow us to put the string inside the argument
to the function directly and thus make the query more readable by
putting it in context.
Refs #5889
|
|
The `#display_name` used in the drop-down on
`ReferentialVehicleJourneys#index` includes the line's company name.
Include this as a field to filter lines by.
Additionally, use `%query%` filtering everywhere. It's going to be
slower, but will produce the same behaviour for all fields for
consistency and is easier for searching by company name when you might
want to filter by a term in the middle of the name.
Refs #5889
|
|
Instead of doing a complex query to get the lines available to filter
on, just get all the lines in the current referential. We then filter
those by what was typed into the select2 box and asynchronously respond
with line options in a new JSON autocomplete controller.
Here we're only providing the option to filter by `number` and `name`
field on the line. I'd like to filter by everything in the
`#display_name`. I don't think the objectid is going to be easy to
integrate into the SQL query but I'd like to add the company part. It's
possible we could do the objectid filter in Ruby instead of the database
query.
Refs #5889
|
|
|
|
|
|
|
|
|
|
|
|
SimpleImporter#dump_csv_from_context. Refs #5924
|
