-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement GET /proposals/{proposalId}
endpoint
#101
Comments
A call to /proposals/{proposalId} returns a single proposal with its immediate attributes. Issue #101 Implement GET /proposals/{proposalId} endpoint
Had we originally decided to return deep objects on all the single-id endpoints? Or should we default to shallow objects on all endpoints and then offer deep objects on some, as suggested around #157 (comment)? PR #192 assumes shallow objects to be the default. The next step would be to allow deep objects when specified. |
A call to /proposals/{proposalId} returns a single proposal with its immediate attributes. Issue #101 Implement GET /proposals/{proposalId} endpoint
A call to /proposals/{proposalId} returns a single proposal with its immediate attributes. Issue #101 Implement GET /proposals/{proposalId} endpoint
I am still working on the deep objects code and tests. But here is an example response when asking to include fields and values with {
"id": 1,
"applicantId": 1,
"opportunityId": 1,
"externalId": "AnIdGeneratedByAGms",
"createdAt": "2022-11-10T20:07:04.695Z",
"versions": [
{
"id": 2,
"proposalId": 1,
"applicationFormId": 4,
"version": 1,
"createdAt": "2023-01-04T16:28:47.276Z",
"fieldValues": [
{
"id": 1,
"proposalVersionId": 2,
"applicationFormFieldId": 3,
"position": 1,
"value": "Jones",
"createdAt": "2023-01-04T16:29:57.877Z",
"applicationFormField": {
"id": 3,
"applicationFormId": 4,
"canonicalFieldId": 280,
"position": 1,
"label": "Family Name",
"createdAt": "2023-01-04T16:27:40.175Z"
}
},
{
"id": 2,
"proposalVersionId": 2,
"applicationFormFieldId": 4,
"position": 2,
"value": "Jim",
"createdAt": "2023-01-04T16:30:08.974Z",
"applicationFormField": {
"id": 4,
"applicationFormId": 4,
"canonicalFieldId": 279,
"position": 2,
"label": "Given Name",
"createdAt": "2023-01-04T16:27:40.175Z"
}
}
]
}
]
} |
A call to /proposals/{proposalId} returns a single proposal with its immediate attributes. Issue #101 Implement GET /proposals/{proposalId} endpoint
When optional query parameter includeFieldsAndValues is set to true on GET /proposals/{proposalId}, include all proposal versions, associated values, and associated application form fields in the response. By returning this almost-fully-deep object tree, it is more convenient for the caller and more efficient in terms of request, query, and response counts. The assumption is that the purpose of the PDC is to see and compare which fields are used for what purpose for proposals. Issue #101 Implement GET /proposals/{proposalId} endpoint
A call to /proposals/{proposalId} returns a single proposal with its immediate attributes. Issue #101 Implement GET /proposals/{proposalId} endpoint
When optional query parameter includeFieldsAndValues is set to true on GET /proposals/{proposalId}, include all proposal versions, associated values, and associated application form fields in the response. By returning this almost-fully-deep object tree, it is more convenient for the caller and more efficient in terms of request, query, and response counts. The assumption is that the purpose of the PDC is to see and compare which fields are used for what purpose for proposals. Issue #101 Implement GET /proposals/{proposalId} endpoint
A call to /proposals/{proposalId} returns a single proposal with its immediate attributes. Issue #101 Implement GET /proposals/{proposalId} endpoint
A call to /proposals/{proposalId} returns a single proposal with its immediate attributes. Issue #101 Implement GET /proposals/{proposalId} endpoint
When optional query parameter includeFieldsAndValues is set to true on GET /proposals/{proposalId}, include all proposal versions, associated values, and associated application form fields in the response. By returning this almost-fully-deep object tree, it is more convenient for the caller and more efficient in terms of request, query, and response counts. The assumption is that the purpose of the PDC is to see and compare which fields are used for what purpose for proposals. Issue #101 Implement GET /proposals/{proposalId} endpoint
Yesterday I got a draft of the alternative approach at #198 (comment) working locally, although it is in a less-than-elegant state right now. My goal is to clean it up a bit today. There will need to be a fourth query to include the application form fields that relate to the proposal values, too. |
Using |
When optional query parameter includeFieldsAndValues is set to true on GET /proposals/{proposalId}, include all proposal versions, associated values, and associated application form fields in the response. By returning this almost-fully-deep object tree, it is more convenient for the caller and more efficient in terms of request, query, and response counts. The assumption is that the purpose of the PDC is to see and compare which fields are used for what purpose for proposals. Issue #101 Implement GET /proposals/{proposalId} endpoint
When optional query parameter includeFieldsAndValues is set to true on GET /proposals/{proposalId}, include all proposal versions, associated values, and associated application form fields in the response. By returning this almost-fully-deep object tree, it is more convenient for the caller and more efficient in terms of request, query, and response counts. The assumption is that the purpose of the PDC is to see and compare which fields are used for what purpose for proposals. Issue #101 Implement GET /proposals/{proposalId} endpoint
When optional query parameter includeFieldsAndValues is set to true on GET /proposals/{proposalId}, include all proposal versions, associated values, and associated application form fields in the response. By returning this almost-fully-deep object tree, it is more convenient for the caller and more efficient in terms of request, query, and response counts. The assumption is that the purpose of the PDC is to see and compare which fields are used for what purpose for proposals. Issue #101 Implement GET /proposals/{proposalId} endpoint
When optional query parameter includeFieldsAndValues is set to true on GET /proposals/{proposalId}, include all proposal versions, associated values, and associated application form fields in the response. By returning this almost-fully-deep object tree, it is more convenient for the caller and more efficient in terms of request, query, and response counts. The assumption is that the purpose of the PDC is to see and compare which fields are used for what purpose for proposals. Issue #101 Implement GET /proposals/{proposalId} endpoint
When optional query parameter includeFieldsAndValues is set to true on GET /proposals/{proposalId}, include all proposal versions, associated values, and associated application form fields in the response. By returning this almost-fully-deep object tree, it is more convenient for the caller and more efficient in terms of request, query, and response counts. The assumption is that the purpose of the PDC is to see and compare which fields are used for what purpose for proposals. Issue #101 Implement GET /proposals/{proposalId} endpoint
When optional query parameter includeFieldsAndValues is set to true on GET /proposals/{proposalId}, include all proposal versions, associated values, and associated application form fields in the response. By returning this almost-fully-deep object tree, it is more convenient for the caller and more efficient in terms of request, query, and response counts. The assumption is that the purpose of the PDC is to see and compare which fields are used for what purpose for proposals. Issue #101 Implement GET /proposals/{proposalId} endpoint
When optional query parameter includeFieldsAndValues is set to true on GET /proposals/{proposalId}, include all proposal versions, associated values, and associated application form fields in the response. By returning this almost-fully-deep object tree, it is more convenient for the caller and more efficient in terms of request, query, and response counts. The assumption is that the purpose of the PDC is to see and compare which fields are used for what purpose for proposals. Issue #101 Implement GET /proposals/{proposalId} endpoint
Simplify implementation further based on review feedback. Issue #101 Implement GET /proposals/{proposalId} endpoint
Simplify implementation further based on review feedback. Issue #101 Implement GET /proposals/{proposalId} endpoint
When optional query parameter includeFieldsAndValues is set to true on GET /proposals/{proposalId}, include all proposal versions, associated values, and associated application form fields in the response. By returning this almost-fully-deep object tree, it is more convenient for the caller and more efficient in terms of request, query, and response counts. The assumption is that the purpose of the PDC is to see and compare which fields are used for what purpose for proposals. Issue #101 Implement GET /proposals/{proposalId} endpoint
Simplify implementation further based on review feedback. Issue #101 Implement GET /proposals/{proposalId} endpoint
When optional query parameter includeFieldsAndValues is set to true on GET /proposals/{proposalId}, include all proposal versions, associated values, and associated application form fields in the response. By returning this almost-fully-deep object tree, it is more convenient for the caller and more efficient in terms of request, query, and response counts. The assumption is that the purpose of the PDC is to see and compare which fields are used for what purpose for proposals. Issue #101 Implement GET /proposals/{proposalId} endpoint
Simplify implementation further based on review feedback. Issue #101 Implement GET /proposals/{proposalId} endpoint
When optional query parameter includeFieldsAndValues is set to true on GET /proposals/{proposalId}, include all proposal versions, associated values, and associated application form fields in the response. By returning this almost-fully-deep object tree, it is more convenient for the caller and more efficient in terms of request, query, and response counts. The assumption is that the purpose of the PDC is to see and compare which fields are used for what purpose for proposals. This commit consolidates incremental changes that should be seen here: #210 Issue #101 Implement GET /proposals/{proposalId} endpoint
There are two more things on the /proposals endpoints before I am comfortable closing this issue.
|
Add more complete details to the OpenAPI documentation, specifically about the `includeFieldsAndValues` query parameter. Also fix a potential bug where a promise could be left hanging. Issue #101 Implement GET /proposals/{proposalId} endpoint
Add more complete details to the OpenAPI documentation, specifically about the `includeFieldsAndValues` query parameter. Also fix a potential bug where a promise could be left hanging. Issue #101 Implement GET /proposals/{proposalId} endpoint
As mentioned in #34 we need the ability to load a specific proposal. We have explored the pattern of populating deep fields when loading a single ID and I think it would be appropriate to do so here as well, which would mean the returned proposal would include the various proposal versions and proposal field values.
The text was updated successfully, but these errors were encountered: