| Age | Commit message (Collapse) | Author |
|---|
|
af83/5366-add-feature-specs-for-the-CRUD-actions-on-PurchaseWindo
5366 add feature specs for the crud actions on purchase windo
|
|
|
|
|
|
|
|
<!> There is no spec (yet)
|
|
|
|
|
|
|
|
|
|
For now no bug has been fixed :-)
|
|
|
|
|
|
|
|
Make company optional in Lines form. Refs #5361
|
|
|
|
And handle the case when it is nil in the views
|
|
Deactivate StopAreas. Refs #5349
|
|
- Update decorators (had to split `action_links` because of
`StopPointDecorator` inheriting from `StopAreaDecorator`)
- Add methods on model
- Add routes
- Add actions on controller (`Activatable` concern, shared with
`LinesController`)
- Add I18n keys
|
|
Deactivate lines instead of destroying them. Refs #5340
|
|
... In Referential#show
|
|
|
|
- Add `activate` and `deactivate` actions in `LinesController`, as well
as corresponding routes
- Add `activate!` and `deactivate!` methods in `Chouette::Line`, as well
as `activated?`
- Add `activate?` and `deactivate?` permissions in `LinePolicy`
- Add corresponding `action_links`in the Decorator
- Create helper for these actions
- Add an optional `'extra_class` to the Links
- Update styles for ".delete-action" to handle the case where there are
several
- Add I18n keys accordingly
|
|
Truncate long breadcrumbs. Refs #5354
|
|
af83/5355-add-button-to-opposite-itinerary-timetable
Add opposite route button on timetables. Refs #5355
|
|
|
|
lines/companies/networks. Refs #5301
|
|
|
|
Check that `PurchaseWindow`s can be destroyed, starting from the
`#index` page.
Update the i18n key used in the decorator to get the text that appears
in the alert when destroying a `PurchaseWindow` so that it correctly
corresponds to the one used in the locale file.
Refs #5366
|
|
Test that `PurchaseWindow`s can be updated starting from the `#index`
page.
Refs #5366
|
|
Add a feature spec that creates a new `PurchaseWindow` from the #index
page.
Fix i18n keys for `simple_form` to correctly show labels inside the form
and be able to identify the correct elements inside the test.
Refs #5366
|
|
|
|
|
|
|
|
|
|
|
|
5316-migrate-compliance-control-and-check-attributes-from-hs
|
|
5358 Fix `undefined` appearing in header
|
|
of github.com:AF83/stif-boiv into 5316-migrate-compliance-control-and-check-attributes-from-hs
|
|
This method must return the keys of all `control_attributes` in
subclasses of `ComplianceControl`.
Now that we're not using `hstore_accessor`, this breaks. Use
`stored_attributes` to get the keys since we create virtual attributes
using Rails' `store_accessor`.
Refs #5316
|
|
Copy Cédric's JSON to Hstore migration for the `down` here to give us
the ability to roll back.
I'm guessing the solution probably comes from here:
https://stackoverflow.com/questions/28315948/casting-json-to-hstore-in-postgres-9-3/28319295#28319295
Refs #5316
|
|
We're no longer using this gem. See:
* b54daa7b2d7925131572e5e5d5181cf3515a6057
* 993650cd1739a3c4c2dd6a4dc01110b57ef88f36
Refs #5316
|
|
The places we were using `hstore_accessor` have now been converted to
Postgres JSON fields. Thus we no longer need `hstore_accessor` in order
to add accessors for the fields.
Instead we can use Rails' built-in support for Postgres JSON fields and
create accessors for our JSON hash keys with `store_accessor`. We get
rid of the data types because `store_accessor` doesn't work like that
and JSON already types our values with primitive data types.
Finally, add some extra validation tests now that the vaildation for our
JSON fields should work.
Refs #5316
|
|
Make these columns JSON fields again. Do this because of bugs trying to
validate types with `hstore_accessor`
(https://github.com/devmynd/hstore_accessor/issues/78).
With a JSON field, types are preserved and we don't have to deal with
casting back and forth.
Previously we had converted to Hstore because the Java IEV application
used an older ORM version (maybe Hibernate) that didn't support the
Postgres JSON type. Because of the validation problems with Hstore, the
Java application has been updated to support JSON fields.
Thanks to this Stack Overflow post from 'a_horse_with_no_name' that
describes how to convert from Hstore to JSON types in Postgres:
https://stackoverflow.com/questions/33732529/postgres-how-to-convert-hstore-to-json-datatypes#comment55234342_33732529
Converting in this direction seems to me to be much safer because we're
not losing type information. All the values should be hashes of strings,
which should convert without issue into JSON.
Refs #5316
|
|
Refs #5301 First draft for Business Calendars
|
|
|
|
5301-add_business_calendars
|
|
|
|
|
|
|
|
|
