| Age | Commit message (Collapse) | Author |
|---|
|
af83/4962-when-WorkbenchImport-is-deleted-also-delete-associated-Referential-if-ready-false
4962 when workbench import is deleted also delete associated referential if ready false
|
|
|
|
|
|
|
|
objectid_support handles reading and writing object_ids
objectid_formater_support gets the right formater class
include these concerns in chouette models
Remove StifNetexAttributSupport modules because these are handled by the new objectid concerns
Add a objectid and formater classes for each format type
Add objectid formats to the factories
Modify somes specs for object_ids but there are still a number of failling tests
|
|
a object_id_format_to_referential module
|
|
Suggestion from Robert.
Refs #4962
|
|
Refs #4516
|
|
Refs #4516
|
|
If the `NetexImport`'s associated `Referential` has `ready: false`, when
the `NetexImport` is destroyed, also destroy the `Referential`.
This prevents a case where users get an invalid `Referential` as a
result of an import, but because of the `ready: false`, it doesn't
display on the website, so they can't see what the problem is.
Refs #4962
|
|
Return `true` from this method by default. If the `#update` call fails,
then it will return `false`, but in all other cases, we should return
`true`. That way, when the
`Api::V1::ComplianceCheckSetsController#validated` endpoint is called,
it will respond with the `ComplianceCheckSet` object instead of:
{"status":"error","messages":[]}
with no error messages.
Refs #4757
|
|
If any associated resources have the "IGNORED" status, this shouldn't
affect the outcome of a "successful" status. Allow the
`ComplianceCheckSet` to be "successful" even if some `Resource`s are
"IGNORED".
Refs #4757
|
|
Another suggestion from Robert, since this method returns a boolean,
maybe its name should end with a question mark.
Refs #4757
|
|
Suggestion from Robert to have a simpler name. I had just written it the
way it sounded in my head when I wrote the method.
Refs #4757
|
|
We should return the result of the `ActiveRecord` `#update` call, so
that we can determine if there was an error saving the
`ComplianceCheckSet` record.
Refs #4757
|
|
This reverts commit b7477e28f90c961079c7b12c4992071cbc11b2d6.
This logic isn't right. We should return true/false based on the result
of `update`, as in, whether the value was able to be updated, instead of
on the contents of the status.
|
|
Ensure that `#update_status` always returns a boolean value. We'll be
using this to determine whether the updated status was 'successful' or
not. Hmmm. Wait. That's not right. We want to return true from the
update, we don't care about the status. The error case should be when
the `update` fails. Darn.
Refs #4757
|
|
Previously we were updating to a 'successful' status prematurely, at the
first encounter with a successful `ComplianceCheckResource`. Here, we
wait until we've looked at all associated `ComplianceCheckResource`s
before setting 'successful'. Only if all associated
`ComplianceCheckResource`s are successful do we set this status on the
`ComplianceCheckSet`.
Refs #4757
|
|
Fill in the `#update_status` method. It should update the status of the
`ComplianceCheckSet` based on the status of its child
`ComplianceCheckResource`s.
This version doesn't work because it doesn't wait until the end of the
loop to update the status to 'successful'. But it's the right logic for
the 'failed' and 'warning' cases.
Refs #4757
|
|
Initial spec that checks the correct status field change when all
`ComplianceCheckResource`s are successful.
Refs #4757
|
|
If the `Import`'s associated `Referential` has `ready: false`, destroy
that `Referential` when the import is destroyed.
Aaand looking back at the task it turns out that's not what I was
supposed to do. Right, it does seem a little weird in retrospect.
Instead we want to delete the `Referential`s of child imports.
Refs #4962
|
|
|
|
|
|
Referential, StopAreaReferential in models, add Enumerize in models Refs #4941
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4802 referential model normalisation
|
|
|
|
|
|
CodeReview:
- Exchange fr and en translation files for referential_suites
- Consistent usage of `jeu de donées` and `espace de travail` dans les *fr.yml
Fixes: #4802@0.2h; Replaying former work. To identify spec regression
Step 3: Added validation of reference_suite#new/current
Made all specs pass
|
|
Step 2: Added validation of reference->workbench->organisation consistency
Made all specs pass
Chased bug #4826
|
|
Step 1: config/locales
|
|
ComplianceControl.subclass_patterns [amend me] [skip-ci]
|
|
Ransack filter view implemented
|
|
|
|
|
|
|
|
|
|
|
|
Refs #4730
|
|
|
|
|
|
|
|
|
|
|
|
Validation implemented for min_max_values with correct I18n'd error messages
Applied to: VehicleJourneyControl::Speed & GenericAttributeControl::MinMax
|
