rubyforgood
Improving the child functionality
Summary
The current child functionality only allows one item per child. It should allow multiple. Show the items attached to the child on various lists.
Why change
This is a sticking point in the use of the child requests for at least some banks/partners. For instance, you might need both diapers and baby wipes, but you can't ask for that.
Details
When entering/editing a child, you should be able to choose multiple items [for example both Baby Wipes and Kids (Size 1)]. You currently can only choose one item.
There will obviously be model changes involved in implementing this, as the item is currently saved as an integer on the child model.
The children export will need to show the multiple items
The child index and the children information in the family should show the items -- for ease of review, as children age out of diaper sizes quickly
The child request index should show all the items attached to each child, and the child request functionality will need to be adjusted to take into account the multiple items.
Adding the ability to change the items needed from the child request page would also be grand, but it can be a followup issue
Notes
@cielf says: I took a look at the production data, and there are remarkably few cases where someone has used the loop hole of entering multiple kids with the same name. Our most engaged banks don't make a lot of use of the child functionality, but to some extent they don't because it isn't good enough - and the reason mentioned most is the lack of multiple items.
Criteria for completion
- [ ] Multiple items can be attached to a child, with all the functionality around families, children and child requests working smoothly with that.
- [ ] Can see the items in the child request index, and the children info in the family
- [ ] tests to support the functionality
Bonus round
- [ ] add the ability to change the items needed from the child request page as well
An idea for you @patelkrunal31 is to make the child's name linkable on the child-request page, so that they could go make quick-edits as needed there. For you to consider :)
This issue is marked as stale due to no activity within 30 days. If no further activity is detected within 7 days, it will be unassigned.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@cielf Can you tell me if this issue is still open for contributions?
I wonder what happened to the other 2 more experienced developers than me on the path of arriving. Will default to "they gave up" if you don't enlighten me about what happened.
From the PR made by Mr. Isidzuki, I learned that it should follow a bit of a "clumpsy-looking" feature, instead of creating a fancy keyboard-activated multi-items selection capability.
Yes it is. I believe that pr was very close to getting merged, but they chose to abandon it.
And I think we need to migrate our has-one into this has-many list of per-child item requests.
@cielf I can take this one. But with your support on bringing more clarity over what is expected also known as DoD, as we talked in the last meeting.
I'm not familiar with the DoD abbreviation, other than as "Department of Defense".
As mentioned, I can add some wireframes -- but I won't get to that until later in the week. (Edit: Possibly later)
As wrritten, this was marked Difficulty-Advanced because it requires a lot of prior familiarity with the system -- the individual bits of coding that have to be done are not so very very hard, but the issue assumed the capacity to know what to do in the context of the system.
@cielf DoD is a Scrum-related abbreviation for Definition of Done. But I will work with what I have and do my best to unstruck this issue that hasn't been handled for some time. I believe my "working unit" (me and the tech mentor) can handle this issue in 2 weeks starting from the day of attribution.
In regards to the front end/wireframe, what I understood from our last meeting was something like that:
If you think that's a good start, I can continue to build it out and present it next Sunday to the team.
Looks like we still have a gap in understanding... The items should be chosen on the child, the child chosen on the request (as they are now).
@cielf I recorded a 2min video pitch of what I built so far. I didn't change quantity of items per child when a request is made, so they appear as 50 units. When 1 item is selected for the child, it is implicitly choosing the child already, but I can implement front end features to reflect as if it had characteristics of what pre-existed, if that is desired. All those aspects would be clearer when the wireframe arrives.
Hope you like it. 🤓 Loom
So the edit child screen would look something like this....
The view child screen would be the same except for showing multiple items. (Label will say item(s) instead of item)
The child request screen would be the same except for showing multiple items. (header will say item(s) instead of item)
Of course, the multiple items will have to be added into the actual request.
for clarity, we are choosing the child, not the items when we are making the request.
A note on your choice for the selection of many items -- The drop-down select many might not work the same across browsers, so it may end up resulting in support issues. That is what drives the version in the wireframe.
What about the quantity of items? should there be a new screen before completing the request and after choosing the child for the amount per item to be inserted? Or is this not relevant for now?
The number of items per child is actually determined by the bank -- there is a field for that on the item itself. For the most part diapers happen to be 50 -- and I believe we default to that if the bank doesn't specify. So that should be handled the same way it is now.
(of course you have to handle each item on the child when creating the actual request -- I would hope that goes without saying g)
@elasticspoon unfortunately in prod data there are children with a item_needed_diaperid set but no corresponding Item record. I'm not sure what caused those.
Mmmm. Interesting you should probably revert and I'll fix the migration later.
It should be an easy fix but I'm not at PC for a bit.
FYI There was only one other, very minor, bank-facing thing on the release, so we're good with holding it to next week.
Also there are only like 7 children records affected now that I dug in a bit, so likely outcome after an investigation is skipping those.
diaper_dev=# select count(distinct(children.id)) from children left join items on children.item_needed_diaperid = items.id where children.item_needed_diaperid is not null and items.id is null;
count
-------
7
That's fair. I would also like to make sure those can't reappear in the future tho. ~~So I'll add tests for the case where the child has items and either the child or item is deleted.~~
Not sure tests actually make sense because there are no controller actions to delete children or items for partners.
FWIW, after taking a look at the child records involved, skipping them does make sense to me. They haven't been updated in over a year.