AdopterFoster Dashboard: As an adopter I can see any incomplete tasks on my adopted pets

[kasugaijin]

This issue #900 was a first step in allowing adopters to see their pets and download their attached records

We should expand on this to enable them to also see any uncompleted tasks on the pet (this will allow the staff to set tasks for the new adopter). This will be READ only access (only staff can complete tasks, this ensures they know it is completed, and can follow up with adopters to make sure things are done).

I think we should set up a new controller, something like Organizations::AdopterFosterer::AdoptedPets::TasksController and on this place an index action that will return the correct collection of tasks for the Pet. We should also have a policy class to ensure that the user is an adopter with :read_pet_tasks access.

If I am an adopter looking at adopted pets in the dashboard, we are currently rendering the files table using turbo stream. But, we really should lean on turbo_frames when that is all that is needed. So, can you please refactor the current implementation that renders the files table to use turbo_frame instead. This means wrapping the section on the Dashboard view in a turbo_frame_tag with an ID, and then on the Organizations::AdopterFosterer::AdoptedPets::FilesController index view template, you can just wrap the table partial, with attachments as a collection, in the same turbo_frame_tag and Turbo should replace that frame with the correct HTML to display the table of files.

Then, please use the same implementation for Organizations::AdopterFosterer::AdoptedPets::TasksController to show the tasks.

For displaying the tasks table, I think all we need to do is use a an existing table partial to display the task name and task description and due date. That is all. No need for any buttons etc to modify tasks. If a table partial does not make sense, feel free to create a new partial based off the tasks table that staff see, but remove the buttons to edit and delete and make a new task. Save this partial in the Organizations::AdopterFosterer::shared scope because it will also be used for fosters.

There may be questions, so ask away!

[kasugaijin]

@sarvaiyanidhi Since you worked on V1 of this, are you interested in doing this V2?

[sarvaiyanidhi]

Sure @kasugaijin I can work on it. Will go through details and get back to you in case of any queries.

[kasugaijin]

Hey @sarvaiyanidhi how's this going? Let me know if you still want to tackle it, or not!

[sarvaiyanidhi]

Hi @kasugaijin ... I am still committed to this issue and will raise PR in coming week.

[kasugaijin]

@sarvaiyanidhi awesome just checking in…no rush

[sarvaiyanidhi]

Hi @kasugaijin , Just one query on requirement, currently we are displaying file details on click of pet card which enroutes to adopter_fosterer_adopted_pet_files_path to fetch details. As we need to now display even task details so do we need to add any additional link to trigger and display tasks as I see you have mentioned above to create new controller to display task details.

Also, I have pushed PR which is in progress with changes suggested in issue to use turbo_frame instead of turbo_stream

[kasugaijin]

@sarvaiyanidhi I have been thinking about this again after your question, thank you.
Re the turbo stream vs turbo frame question, currently because we do not include the pet cards in the turbo frame tag, I don't think we can actually implement this using turbo frames like I mentioned.

Re the loading of two resources, if we have two separate resources - one for the files, one for the tasks, we could keep the structure you have now, where the pet card links to the files resource, and then within that files resource turbostream response, we could include another turbo frame tag for the tasks with a src attribute (https://turbo.hotwired.dev/handbook/frames#eager-loading-frames) that will then make an async request to get the tasks and populate them on the page.

I wonder if there is a better way to handle this, though, using just turbo frames. What do you think of this...

• we include the pet cards within the turbo frame tag, each is wrapped in a link to the adopted pets path with their pet id
• beneath the pets, we have a turbo frame tag with a src attribute to get the files for a pet from the files resource
• beaneath the files, we have a turbo frame tag with a src attribute to get the incomplete tasks for a pet from the tasks resource
• all we need to do then is set the pet id in these src links
• when a user clicks on a pet card, turbo frame will hit the adopted pets index and reload the entire frame, but this time with the correct pet ids in the frames with a src attribute, and this will make async requests to each resource
• I think this will work and will be cleaner.

[sarvaiyanidhi]

Thank you @kasugaijin.

I think the suggested approach sounds good and should work with our requirement by just using turbo_frame.

As you can see in existing PR I have already removed turbo_stream and using turbo_frame with link targeting data_turbo_frame 'pet_files" to fetch details so I think I can just extend this to get tasks using src attribute below this