Follow+Notes: Retrieve note(s) for grant by a specific user via Finder API

[TylerHendrickson]

Subtask of [STORY]: Update 'Status' to 'Follow + Note' feature #2960

Blocked by

N/A

Blocks

• Follow+Notes: Implement note input and note feed on Grant Details view #3428

Definition of Done

A new API route exists that allows retrieval of the latest revision for each note pertaining to a specific user and grant.

Implementation Details

• In packages/server/src/lib/grantsCollaboration/notes.js, update the exported interface with the following functions:
  • getOrganizationNotesForGrantByUser(knex, organizationId, userId, grantId, { afterRevision, limit = 50 } = {})
    • Queries for the most-recent revision of each grant note pertaining to the identified grant and user.
    • Results should be ordered by grant_notes_revisions.created_at in descending order (most recent first).
    • To implement this functionality, I recommend the following approach (which avoids reimplementing database query behavior and maintains compatibility with existing functionality and associated tests):
      • Rename the existing getOrganizationNotesForGrant() function to getCurrentNoteRevisions() and update it's argument signature to (knex, { grantId, organizationId, userId } = {}, { afterRevision, limit = 50 } = {}).
      • Modify the body of the newly-renamed getCurrentNotesRevisions() function so that the WHERE filters of the query pertaining to grant_notes.grant_id = :grantId and grant_notes.user_id = :userId are conditional and only applied when grantId and userId are not null/undefined. In other words, we want to make the behavior of limiting query results to those pertaining to a specific user and/or grant optional.
      • Write the new getOrganizationNotesForGrantByUser() function as a simple wrapper that calls getCurrentNotesRevisions() and returns the return value from that internal call, e.g.

        function getOrganizationNotesForGrantByUser(knex, grantId, organizationId, userId, { afterRevision, limit = 50 } = {}) {
            return getCurrentNoteRevisions(knex, { grantId, userId }, { afterRevision, limit });
        }

        This function should be exported by the packages/server/src/lib/grantsCollaboration/notes.js module.
      • Similarly, write a new exported getOrganizationNotesForGrant(knex, grantId, organizationId, { afterRevision, limit = 50 } = {}) function (which implements the same original call signature) as another simple wrapper for getCurrentNoteRevisions(), e.g.

        function getOrganizationNotesForGrant(knex, grantId, organizationId, { afterRevision, limit = 50 } = {}) {
            return getCurrentNoteRevisions(knex, { grantId, organizationId }, { afterRevision, limit });
        }

• In packages/server/src/lib/grantsCollaboration/index.js, import/export the getOrganizationNotesForGrantByUser() function exported from packages/server/src/lib/grantsCollaboration/notes.js
• In packages/server/src/routes/grants.js, define a new GET /:grantId/notes/user/:userId API route handler as follows:
  • Requires authentication.
  • Calls getOrganizationNotesForGrantByUser() from packages/server/src/lib/grantsCollaboration to retrieve a (paginated) result set of notes pertaining to the grant, organization, and user identified in the request.
    • The grantId and userId call arguments to getOrganizationNotesForGrantByUser() should all be derived from the corresponding request path parameter (req.params) values.
    • The organizationId call argument to getOrganizationNotesForGrantByUser() should be the tenant_id of the user provided by the request session (req.session.user.tenant_id)
    • If a ?paginateFrom query parameter value is provided in the request, that value should be provided as the afterRevision argument in the call to getOrganizationNotesForGrantByUser().
    • If a ?limit query parameter value is provided in the request, that value (as a parsed integer) should be provided as the limit argument in the call to getOrganizationNotesForGrantByUser(). Additionally, this value must pass the following validation checks (or else respond with a 400 Bad Request status):
      • Can be successfully parsed as an integer
      • Parsed integer value must be greater than or equal to 1
      • Parsed integer value must not exceed 100
  • Following a successful call to getOrganizationNotesForGrantByUser(), provides the function's return value as a JSON-serialized response.

[sushilrajeeva]

@TylerHendrickson The approach you suggested -

function getOrganizationNotesForGrantByUser(knex, grantId, organizationId, userId, { afterRevision, limit = 50 } = {}) { return getCurrentNoteRevisions(knex, { grantId, userId }, { afterRevision, limit }); }

for creating getOrganizationNotesForGrantByUser function, we are not utilizing the organizationId parameter. I am currently following your steps but is this something we should revisit?

[TylerHendrickson]

@sushilrajeeva re

@TylerHendrickson The approach you suggested -

function getOrganizationNotesForGrantByUser(knex, grantId, organizationId, userId, { afterRevision, limit = 50 } = {}) { return getCurrentNoteRevisions(knex, { grantId, userId }, { afterRevision, limit }); }

for creating getOrganizationNotesForGrantByUser function, we are not utilizing the organizationId parameter. I am currently following your steps but is this something we should revisit?

Good spot! I think it would be best to keep the getOrganizationNotesForGrantByUser() signature the same and provide organizationId in the underlying call, e.g.

function getOrganizationNotesForGrantByUser(knex, grantId, organizationId, userId, { afterRevision, limit = 50 } = {}) {
    return getCurrentNoteRevisions(knex, { grantId, organizationId, userId }, { afterRevision, limit });
}

This will help ensure that results can always be limited to a particular organization.

[sushilrajeeva]

@TylerHendrickson Thanks, I will do this, it gives more flexibility in the future.