Display count of all CVE records from CVE Services on homepage

[athu-tran]

Enhancement to #31 (total number of CVE records on landing page) by integrating with CVE Services

As a general user, I want to see the total number of CVE records to date so that I can stay informed.

Acceptance Criteria:

• Displays only published CVE records where state = published
• CVE records count displays on the home page if the count successfully loads, else display an error message

Linked CVE Services request: CVEProject/cve-services#386

child of #135

[david-waltermire]

The following issues are needed to support this feature:

• RSUS - 1A - Include count property in get record requests (RSUS - 1A - Include count property in get record requests cve-services#301)
• RSUS - 1A - count only parameter (count only parameter cve-services#289)

[athu-tran]

@david-waltermire-nist: Thanks Dave for providing those mappings. I think we need to discuss them in detail. From what I understand the website working group hasn't finalized requirements for those user stories yet which is need to determine if those RSUS user stories are a good fit. Let's circle back on this.

[david-waltermire]

This looks good to me.

Why are we creating new requests (i.e., CVEProject/cve-services#386) when we have existing user stories (i.e., CVEProject/cve-services#289) that are also referenced by the new request?

This approach makes it harder to follow the actual work being done. This level of indirection will require the AWG to mark both issues as complete, when the actual work has been done, which seems like extra work with little to no value.

[athu-tran]

This looks good to me.

Why are we creating new requests (i.e., CVEProject/cve-services#386) when we have existing user stories (i.e., CVEProject/cve-services#289) that are also referenced by the new request?

This approach makes it harder to follow the actual work being done. This level of indirection will require the AWG to mark both issues as complete, when the actual work has been done, which seems like extra work with little to no value.

Good question. CVEProject/cve-services#289 is the endpoint that we need to use but the work hasn't yet been started, and there are also additional backend work outside of 289 that needs to be work done. Therefore, 386 was filed to track that those dependencies.

In general, any website dependencies on CVEProject/cve-services is filed as a ticket to track the work. Complete list of CVE Services dependencies are on the CVE Website Data Support Requests page. I agree that it does create more work but it helps the website and the CVE Services Teams track work.

[david-waltermire]

Good question. CVEProject/cve-services#289 is the endpoint that we need to use but the work hasn't yet been started, and there are also additional backend work outside of 289 that needs to be work done. Therefore, 386 was filed to track that those dependencies.

You could say then that the work on issue CVEProject/cve-services#386 also hasn't started, so do you need yet another issue because of that with endless recursion? All snarkyness aside, I believe creating duplicate issues is not a good practice. It is better to directly track the work that needs to be done.

Also the "backend" work that needs to be done is not detailed (or even mentioned) in CVEProject/cve-services#386. It not even clear if there is any additional work that needs to be done in the cve-services to address this. Again I question the value of this issue.

In general, any website dependencies on CVEProject/cve-services is filed as a ticket to track the work. Complete list of CVE Services dependencies are on the CVE Website Data Support Requests page. I agree that it does create more work but it helps the website and the CVE Services Teams track work.

Why not just link issue CVEProject/cve-services#289 to the CVE Website Data Support Requests page milestone then? Again, the extra indirection doesn't add clarity.

[athu-tran]

@david-waltermire-nist I would like to talk through the above conversation in the next meeting. Are you able to attend?

[david-waltermire]

@athu-tran Yes. I'll be there.