-
-
Notifications
You must be signed in to change notification settings - Fork 471
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
Improving the child functionality #3797
Comments
I would love to explore this one. |
Give it a shot! |
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. |
Automatically unassigned after 7 days of inactivity. |
@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... |
@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. 🤓 |
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. |
Check how it is calculated now for the single item per child case... |
(of course you have to handle each item on the child when creating the actual request -- I would hope that goes without saying g) |
Automatically unassigned after 7 days of inactivity. |
@elasticspoon unfortunately in prod data there are children with a |
er -- and the release is blocked until we fix or revert, FYI |
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.
|
That's fair. I would also like to make sure those can't reappear in the future tho. 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. |
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
Bonus round
The text was updated successfully, but these errors were encountered: