| Age | Commit message (Collapse) | Author |
|---|
|
- using webmock instead of mocking Net::HTTP
therefore removing the connascence between the spec and the
HTTP lib used in the implementation, thank you Teddy
|
|
|
|
|
|
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
|
|
Move the successful `ComplianceCheckResource`s to the end so that these
tests fail if we don't wait until the end of a loop through the resoures
before updating the status to 'successful'.
Refs #4757
|
|
Add test cases for status update when `ComplianceCheckResource` are
"ERROR" and "WARNING". If a single Resource is "ERROR" or "WARNING",
then the `ComplianceCheckSet` becomes "failed" or "warning".
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
|
|
After a discussion with Luc yesterday, the URL we settled on was:
/api/v1/compliance_check_sets/:id
This matches the format of the import API route a little better.
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
|
|
|
|
|
|
af83/4953-compliance_check_resources--change-type-column-to-resource_type
compliance_check_resources: Rename `type` column to `resource_type`
|
|
The Java application needs a `resource_type` column to be able to store
the class/object that was validated by the resource's check. Since we
don't need or want Single Table Inheritance on this table, rename the
existing `type` field to `resource_type`.
Refs #4953
|
|
Migrate all foreign keys to `bigint` from `integer`
|
|
I had missed this one in 63d85933ac99453c76df7cda102a4f60d94f5f53.
Thanks a lot to Robert for scouring the fields and finding it.
Since the v2 migration was irreversible, add a new one to change the
type of this foreign key.
Refs #4947
|
|
All our primary keys are supposed to be `bigint`s, and our foreign keys
should likewise be `bigint`s. But it's easy to forget this when creating
migrations, or some committers might not have been up to speed on the
convention. In any case, this changes all existing foreign keys to be
`bigint`s.
Need to get this out now so that Michel Etienne can use it to correctly
test the Java application for compliance check validations. That's why
I'm not including any future-looking checks or enforcements here. That
will be coming next.
Refs #4947
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4755 page for validate referential
|
|
|
|
add specs
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ComplianceControlSetCopyWorker, and change routes/views for select compliance_control_set
|
