| Age | Commit message (Collapse) | Author |
|---|
|
- Update the form
- Use policies and update the seeds accordingly
- Add a link in the navbar(s)
|
|
|
|
|
|
|
|
|
|
And define policies
|
|
|
|
And rename resource methods for better consistency
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I previously tried to correct a circular dependency problem in
a057276129b1f62b811743db3b8f867a05241ed3, but that didn't fix it (it was
intermittent, and came back).
After some wrangling, I've now deduced with some confidence that the
problem comes from `RouteWayCostCalculator`, which used
`TomTom::Matrix::RemoteError`. From the way it looks, this seems to mess
up the Rails autoloader since `tom_tom.rb` will try to load the `Matrix`
class from the `TomTom.matrix` call above. Or something.
In an attempt to fix the circular dependency error for real this time,
move the error class to a completely separate module from `Matrix`, and
refer to this when we need to use the error class.
Refs #6884
|
|
6920 activate newly created referentials
|
|
Fix schedules editor. Refs #6864
|
|
|
|
|
|
|
|
As long as one arrives after 11pm and leaves before 1am
|
|
|
|
|
|
|
|
If there's an API error, we shouldn't update the route's `costs` field.
Let's say we've already calculated some costs for a route A. We then edit
and re-save A, which triggers a recalculation of the costs. Now the
TomTom API responds with an error. We don't want to overwrite our
existing costs with an empty array because they could still be useful.
In this case, we should instead keep the existing costs we already had.
To achieve this, move the `RemoteError` rescue into
`RouteWayCostCalculator`, leaving the error unhandled in
`TomTom.matrix`.
Refs #6884
|
|
6627: Add Chouette favicon
|
|
6572 Create Referentials in a pending state
|
|
And fix a bug preventing the deletion of referentials without a schema
|
|
Disable the checkboxes next to pending referentials. This prevents them
from being deleted by the batch deletion operation.
In general it seems like we shouldn't be operating on pending
referentials, so if any new batch actions are added, it would make sense
to me for the checkboxes to stay disabled.
We want to disallow deletion of pending referentials because this can
put the data in an inconsistent state that requires manual intervention
to clean (I think).
Refs #6858
|
|
|
|
|
|
|
|
|
|
Adds a favicon to the site to respond to these errors:
ActionController::RoutingError (No route matches [GET] "/favicon.ico"):
Using `favicon_link_tag` allows us to get the image from the asset
pipeline, which makes it easier to update if necessary, since browsers
tend to cache the default `/favicon.ico` indeterminably (source:
http://api.rubyonrails.org/classes/ActionView/Helpers/AssetTagHelper.html#method-i-favicon_link_tag).
According to some Stack Overflow posts I've been reading, it looks like
it's advisable to put the `favicon.ico` file in both `/assets/images/`
and `/public/`:
- https://stackoverflow.com/questions/15687506/actioncontrollerroutingerror-no-route-matches-get-favicon-ico-in-rails#15688041
- https://stackoverflow.com/questions/11071445/favicon-in-ruby-on-rails-application
This way, you can serve the favicon from the asset pipeline, but if any
requesters try to get `/favicon.ico`, the server will respond with the
image instead of an error.
To be honest, when I was testing locally, I couldn't get the icon in
`/public` to display, both without a `link` tag and with the following
`link` tag:
/ application.html.slim
/ ...
link href='/favicon.ico' rel='shortcut icon'
As a result, I'm adding the image to `/public` with fingers crossed that
it's going to work if requested.
I generated the `favicon.ico` file with a 256x256px PNG supplied by
Cyrielle in the Redmine ticket and the following ImageMagick command:
$ convert -resize x16 -gravity center -crop 16x16+0+0 \
Logo_Chouette-256x256.png -flatten -colors 256 favicon.ico
(Copied from:
https://stackoverflow.com/questions/3185677/converting-gifs-pngs-and-jpgs-to-ico-files-using-imagemagick)
Refs #6627
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
