aboutsummaryrefslogtreecommitdiffstats
path: root/db
AgeCommit message (Collapse)Author
2018-02-22Keep original slug format (with _). Avoid full numeric slug. Refs #56095609_slug_formatAlban Peignier
2018-02-20Refs #5765 @6h; Add a customizable importer mechanismZog
2018-02-07Update branch according to mastercedricnjanga
2018-02-07Refs #5682; Add application_days field to calendarsZog
2018-02-07Refs #5750 @1h; Add a "kind" attribute to StopAreasZog
This determines if the StopArea is commercial or not The useless fields are hidden in the form for the non-commercials ones
2018-02-07First draft for including calendars into workgroup for having appropriate ↵cedricnjanga
scoping
2018-02-07Set all existing `StopArea`s with nil `kind`s to `:commercial`Teddy Wing
The other migration for this in `db/migrate/20180126134944_add_kind_to_stop_areas.rb` didn't handle `kind IS NULL`. Since all the `kind`s were initialised to NULL when the column was created, the `where` query didn't select any stop areas because it was looking for those with some varchar value, and thus it wasn't able to update any. This ensures our existing records all have a `kind` in case we end up using the field in a template at some point and our old data bugs out. Refs #5817
2018-02-07Refs #5750 @1h; Add a "kind" attribute to StopAreasZog
This determines if the StopArea is commercial or not The useless fields are hidden in the form for the non-commercials ones
2018-02-06Update calendar form_simple according to workgroupcedricnjanga
2018-02-06First draft for including calendars into workgroup for having appropriate ↵cedricnjanga
scoping
2018-02-06Refs #5750 @1h; Add a "kind" attribute to StopAreasZog
This determines if the StopArea is commercial or not The useless fields are hidden in the form for the non-commercials ones
2018-02-06First draft for including calendars into workgroup for having appropriate ↵cedricnjanga
scoping
2018-02-06Refs #5758 @1h; Add localized names to StopAreasZog
2018-02-06Refs #5682 @3h; Use same UI as for timetablesZog
2018-02-06Refs #5682; Set default value for application daysZog
2018-02-06Refs #5682; Add application_days field to calendarsZog
2018-02-06Refs #5750; Fix validationZog
2018-02-06Refs #5750 @1h; Manage non-commercial StopAreasZog
- Add a `kind` attribute - Hide irrelevant fields in the form
2018-02-06Refs #5750 @1h; Add a "kind" attribute to StopAreasZog
This determines if the StopArea is commercial or not The useless fields are hidden in the form for the non-commercials ones
2018-01-23First draft for including calendars into workgroup for having appropriate ↵cedricnjanga
scoping
2018-01-22Comment user and operator A creation in stif seedLuc Donnet
2018-01-16Finalize CSV export for ComplianceCheckMessage and Import<essagecedricnjanga
2018-01-12Refs #5163cedricnjanga
Add compliance check resource status helper Add small changes for CSV export
2018-01-11Add Referential#merged_at and make Referentials archived and merged. Refs #5559Alban Peignier
2018-01-10Use jsonb and default to create vehicle_journeys#custom_field_values. Refs #55055505-custom_fields_with_jsonbAlban Peignier
2018-01-10Fixes: #5505@0.25h; Invesitgating the failure to compute a distinct join on ↵Robert
vehicle_journeys Solution: custom_field_values: json -> jsonb
2018-01-10Fixes: #5505@2h; Migrations, specs and implementationsRobert
- Migration index_resource_type_on_custom_fields - Specing behavior of custom field's resource (VehicleJourney) - Migration create json col custom_field_values for resource (VehicleJourney) - Create accessor methods inside resource (VehicleJourney)
2018-01-10Refs: #5505@1h; Spec discussed, model scaffolded [amend me] [skip-ci]Robert
2018-01-10Create STIF Workgroup in seed. Associate existing Workbenchs. Refs #5499Alban Peignier
2018-01-10Fixes: #5499; Added validations and associationsRobert
2018-01-10bup [amend me] [skip-ci]Robert
2018-01-10Refs: #5499@0.5h; fixed migration (ids type of rails generator is not conform)Robert
2018-01-10Refs: #5499@0.5h; Scaffolded WorkgroupRobert
Next: - spec associations and name - spec initialisation - implement
2018-01-09Commit schemacedricnjanga
2018-01-08Remove 'mode' from 'clean_ups', merge mistakeZog
2018-01-08Remove experimental 'objectid' extensionZog
2018-01-08Rebase master5455-store-costs-between-stopsZog
2018-01-08Refs #5455 @6h; Add time and distance between stops in Journey PatternsZog
- Adds a `JSON` attribute in the model - Adds the fields in the editor
2018-01-05Create Merge operation. Refs #5299Alban Peignier
2018-01-04Refs ##5461 Add validation on some Compliance Controls to avoid negative ↵cedricnjanga
values on dynamic attributes
2018-01-04Commit schemacedricnjanga
2017-12-27Refs #5407; Fix CIZog
2017-12-27Refs #5407;Zog
:fire: useless code Rename some vars
2017-12-27Refs #5407; Fix CIZog
2017-12-27Refs #5407 @2h; Model implementationZog
- Link PurchaseWindows to VehicleJourneys in the model - Add an autocompletion endpoint
2017-12-21Merge branch 'master' into ↵Luc Donnet
5316-migrate-compliance-control-and-check-attributes-from-hs
2017-12-21Add `down` to 20171218174509 Hstore to JSON migrationTeddy Wing
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
2017-12-21Change `compliance_{controls,checks}` `control_attributes` to JSONTeddy Wing
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
2017-12-21Merge pull request #150 from af83/5301-add_business_calendarsLuc Donnet
Refs #5301 First draft for Business Calendars
2017-12-21Refs #4787 Add waiting time unitycedricnjanga
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-17 06:14:05 +0000