OBPIH-6853 build table for TO RESOLVE tab#5025
Conversation
github-actions
bot
added
type: feature
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #5025 +/- ##
=========================================
Coverage 7.79% 7.79%
Complexity 868 868
=========================================
Files 620 620
Lines 42744 42744
Branches 10370 10370
=========================================
Hits 3334 3334
Misses 38914 38914
Partials 496 496 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| // TODO: We need to display only the rows where cycle count in [INVESTIGATING, COUNTED]. | ||
| // This will require us to be able to filter on the cycle count status, not just the cycle | ||
| // count request status! So we need to be able to support fetching by a list of values, | ||
| // or we need the get candidate API to internally fetch both. |
There was a problem hiding this comment.
Lets discuss this. Three solutions:
First solution is to change the get cycle count candidates API to filter by cycle count status instead of cycle count request status. Then change the API to allow for multiple statuses to be passed in.
Second solution is to change cycle count request status to contain all the statuses that the cycle count has. Then change the API to allow for multiple statuses to be passed in. We could make cycle count request status be 100% derived from cycle count status (and not a value in the db).
Third solution is to change the get cycle count candidates API to accept allow the following values for "status" to be provided:
- NO_REQUEST
- TO_COUNT
- TO_RESOLVE
- TO_REVIEW
and then map those values to the underlying tables like the following in the get cycle count candidates API:
switch (command.status) {
case NO_REQUEST:
// fetch all rows where no active cycle count request
case TO_COUNT:
// fetch all rows where cycle count request is active and cycle count status in [REQUESTED, COUNTING]
case TO_RESOLVE:
// fetch all rows where cycle count request is active and cycle count status in [COUNTED, INVESTIGATING]
case TO_REVIEW:
// fetch all rows where cycle count request is active and cycle count status in [READY_TO_REVIEW]
}
There was a problem hiding this comment.
I'll let this question be answered by this task: https://pihemr.atlassian.net/browse/OBPIH-6931?atlOrigin=eyJpIjoiOGE1MTUwNWMxOTUyNDhhYzhhMTIzMzdiYzcxNTIyZDkiLCJwIjoiaiJ9
I won't implement it in this PR so it can stay as a TODO for now
| <TableCell className="rt-td"> | ||
| <StatusIndicator | ||
| variant="primary" | ||
| status={translate(`react.cycleCount.table.status.${getValue()}.label`, 'To Resolve')} |
There was a problem hiding this comment.
I wasn't sure how we normally translate values like this. The possible values are defined in an enum on the backend. In message.properties it's defined like:
react.cycleCount.status.COUNTED.label=To Resolve
react.cycleCount.status.INVESTIGATING.label=Resolution In Progress
...
| }; | ||
| spinner.show(); | ||
| try { | ||
| await cycleCountApi.startCount(payload, currentLocation?.id); |
There was a problem hiding this comment.
you can also change the name of the method here to probably startResolution
There was a problem hiding this comment.
it actually uses the same startCount API https://pihemr.atlassian.net/browse/OBPIH-6898
ewaterman
force-pushed
the
ft/OBPIH-6853-populate-to-resolve-tab
branch
from
eb5f8b9 to
191321c
Compare
2 participants
✨ Description of Change
Link to GitHub issue or Jira ticket:
Description:
The TO RESOLVE tab now contains a table like the TO COUNT tab with all the same filter abilities. For now the table contains a row for all cycle count requests where status == CREATED. There's a todo in the code to filter this down to only rows where the cycle count == COUNTED or INVESTIGATING, but that will require changes to the get cycle count candidates API to be able to filter by cycle count status (and not just cycle count request status) so I left that as a TODO for now.
📷 Screenshots & Recordings (optional)