| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
depending on user permissions
|
|
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
|
|
On successful status update, respond with the `ComplianceCheckSet`
object attributes. Otherwise, respond with an error JSON.
Refs #4757
|
|
Get the `ComplianceCheckSet` from the URL and call its `#update_status`
method.
This doesn't currently work all the way. We need to send a real
response.
Refs #4757
|
|
This route will be called by the Java application when ComplianceCheck
validation is completed.
It will perform post-validation work, primarily updating statuses.
Refs #4757
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4755 page for validate referential
|
|
add specs
|
|
|
|
|
|
|
|
|
|
|
|
ComplianceControlSetCopyWorker, and change routes/views for select compliance_control_set
|
|
4802 referential model normalisation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
af83/4782-create-worker-for-compliance-check-copy--rb201710301748
4782 create worker for compliance check copy rb201710301748
|
|
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
|
|
Refs #4820
|
|
Refs #4820
|
|
@indirect_compliance_controls into controller
|
|
View correctly implemented, but spex on filters do not work yet.
|
|
ComplianceControl.subclass_patterns [amend me] [skip-ci]
|
|
Speced feature compliance_control_set/show and filtering on Severity
MISSING: Object Filter needs 2B specified
|
|
|
|
Ransack filter view implemented
|
