Update "4. Enter Travel Details" section on Case Contact Form
What type(s) of user does this feature affect?
- volunteers
- supervisors
- admins
Description
This is part of The Case Contact Form Improvement Epic. If you have any questions, please reach out to me, @bcastillo32, and/or @mallorypricedesign. The Case Contact form is one of the most important and heavily used features and your contribution will have a huge impact on CASA volunteers! :)
Reference Materials
Steps to view a Figma prototype:
- Access the provided link in your web browser.
- Press the play button located at the top right of the browser window.
- (Optional) Create a free account and log in. This grants access to view comments left on the file.
- (Optional) If the prototype extends beyond your screen width, click the "options" dropdown at the top right of the screen and select "fit width."
- Explore the prototype by clicking different areas to discover interactive elements.
Styling Chart
Accessing the Case Contact Form
- Login as a Volunteer
- Click on a case
- Click "+ New Case Contact" button
Current Version
Updated version (from Figma File) https://www.loom.com/share/9c28d091270649c484ccd49198f0477f
Acceptance Criteria
- card header should read "1. Travel details (optional)" - see Figma file and styling chart referenced above
- each section of card should be updated to match Figma File - see Figma File and styling chart referenced above
- Card text should use correct styling - see Figma file and styling chart referenced above
- break up card into the 2 sections.
- Second Section Header should read "2. Other expenses (optional)" and styling and text should match the Figma file/prototype and styling chart.
How to access the QA site
Login Details:
Link to QA site
Login Emails:
- [email protected] view site as a volunteer
- [email protected] view site as a supervisor
- [email protected] view site as an admin
- [email protected] view site as an all casa admin
- go to
/all_casa_admins/sign_in
- go to
password for all users: 12345678
Questions? Join Slack!
We highly recommend that you join us in slack https://rubyforgood.herokuapp.com/ #casa channel to ask questions quickly. And discord for office hours (currently Tuesday 5-7pm Pacific), stakeholder news, and upcoming new issues.
Hey @bcastillo32 - I'd love to work on this. Can you please assign it to me?
Hey @bcastillo32 - I've a question here.
- Now for the address field, we have a states dropdown. Do we have to implement the same states as shown in the Figma?
- Because I believe states depend upon the entered country.
- How do we want to handle this? Thanks.
I believe PlainAdmin uses the native browser dropdown styling. if that's correct, let's go with that. As far as country goes, I think our target users are located in the US. Is this correct @bcastillo32 ?
I believe PlainAdmin uses the native browser dropdown styling. if that's correct, let's go with that. As far as country goes, I think our target users are located in the US. Is this correct @bcastillo32 ?
Yes! users are in the US. @chahmedejaz
This issue has been inactive for 240 hours (10.00 days) and will be unassigned after 120 more hours (5.00 days). If you have questions, please
If you are still working on this, comment here to tell the bot to give you more time
I'm working on it however, I'm sick these days. Will continue the work soon. Thanks.
hi @chahmedejaz I just saw your comment and hope you are feeling better! Let us know if there is anything we can do to help or if you are experiencing any blockers. Feel better soon! ❤️
This issue has been inactive for 241 hours (10.04 days) and will be unassigned after 119 more hours (4.96 days). If you have questions, please
If you are still working on this, comment here to tell the bot to give you more time
This issue has been inactive for 361 hours (15.04 days) and is past the limit of 360 hours (15.00 days) so is being unassigned.You’ve just been unassigned from this ticket due to inactivity – but feel free to pick it back up (or a new one!) in the future! Thank you again for your contribution to this project.
I'm working on it however, I'm sick these days. Will continue the work soon. Thanks.
Hi @chahmedejaz how are you feeling? are you ok? Please let me know. I hope all is well.
Hi @chahmedejaz how are you feeling? are you ok? Please let me know. I hope all is well.
I'm feeling much better now, thanks for asking :innocent: I've some concerns regarding regarding the new address field. let me do some spike and get back to you on this. Thanks.
Hi @chahmedejaz how are you feeling? are you ok? Please let me know. I hope all is well.
I'm feeling much better now, thanks for asking 😇 I've some concerns regarding regarding the new address field. let me do some spike and get back to you on this. Thanks.
Great to hear you are feeling better. and ok sounds good. let us know how we can be of help. 👍🏼
Hey - I'm getting a little busier with my office these days. I might not be able to complete it soon. Sorry for holding this for a long time 😢 Anyone can pick this up.
@bcastillo32 I'll take this.
@bcastillo32 I'll take this.
Hi @ycorredius thank you! Assigning you now!
This issue has been inactive for 263 hours (10.96 days) and will be unassigned after 97 more hours (4.04 days). If you have questions, please
If you are still working on this, comment here to tell the bot to give you more time
This issue has been inactive for 383 hours (15.96 days) and is past the limit of 360 hours (15.00 days) so is being unassigned.You’ve just been unassigned from this ticket due to inactivity – but feel free to pick it back up (or a new one!) in the future! Thank you again for your contribution to this project.
This issue has been inactive for 599 hours (24.96 days) and is past the limit of 360 hours (15.00 days) so is being unassigned.You’ve just been unassigned from this ticket due to inactivity – but feel free to pick it back up (or a new one!) in the future! Thank you again for your contribution to this project.
If this is open, I'd be glad to work on it @bcastillo32
@bcastillo32 You can assign it to @JoshDevHub. I didn't have time to complete this.
This issue has been inactive for 246 hours (10.25 days) and will be unassigned after 114 more hours (4.75 days). If you have questions, please
If you are still working on this, comment here to tell the bot to give you more time
hi @JoshDevHub how are you coming along? Are you experiencing any blockers? any questions? :)
hi @bcastillo32
It's coming along. A rough todo list of remaining tasks:
- add dollar sign to the "expense amount" field
- split address field up into different sections for street, city, state, etc.
- little details with button styling
Most other changes have been made. The address thing may take me some time to work through because it'll surely involve some digging into how the form is consumed on the backend.
No blockers for now though. Will let you know if/when we run into one :thumbsup:
hi @bcastillo32
It's coming along. A rough todo list of remaining tasks:
- add dollar sign to the "expense amount" field
- split address field up into different sections for street, city, state, etc.
- little details with button styling
Most other changes have been made. The address thing may take me some time to work through because it'll surely involve some digging into how the form is consumed on the backend.
No blockers for now though. Will let you know if/when we run into one 👍
Thanks for the update @JoshDevHub - if you need help please let me know and feel free to reach out in our slack in our #proj-case-contact-refactor channel.
Hi @bcastillo32
We're still working on this, and we had some questions about the new way the form is handling the address field.
Currently, the address is all one text string. This is the case for both the form and how the data is stored internally in the database:
The updated design segments the address into different parts in the form like this:
But this creates a discrepancy between how the data is stored (all in one string), and how it is displayed in this form. This can be especially a problem for the existing data on the site, which may or may not neatly fit into the new way this is organized. It's difficult to guarantee the existing data will play nicely with this update.
I think to do this well, we'd have to add new fields to the addresses table. Currently it's like this:
create_table "addresses", force: :cascade do |t|
t.string "content" # string that holds full address
t.bigint "user_id", null: false
end
when it would map better to the new form as something like:
create_table "addresses", force: :cascade do |t|
t.string "street_address"
t.string "city"
t.string "state"
t.string "zip_code"
t.bigint "user_id", null: false
end
But this would require a migration from the way the data is currently organized into a new way of doing it, which would definitely be out of scope for this ticket.
We could also try writing something that would separate the one string up into constituent pieces, but I'd estimate this would likely run into issues with the way people have formatted their addresses, used punctuation, etc. under the current system.
Do y'all have any thoughts for how to proceed with this?
Hi @bcastillo32
We're still working on this, and we had some questions about the new way the form is handling the address field.
Currently, the address is all one text string. This is the case for both the form and how the data is stored internally in the database:
The updated design segments the address into different parts in the form like this:
But this creates a discrepancy between how the data is stored (all in one string), and how it is displayed in this form. This can be especially a problem for the existing data on the site, which may or may not neatly fit into the new way this is organized. It's difficult to guarantee the existing data will play nicely with this update.
I think to do this well, we'd have to add new fields to the
addressestable. Currently it's like this:create_table "addresses", force: :cascade do |t| t.string "content" # string that holds full address t.bigint "user_id", null: false endwhen it would map better to the new form as something like:
create_table "addresses", force: :cascade do |t| t.string "street_address" t.string "city" t.string "state" t.string "zip_code" t.bigint "user_id", null: false endBut this would require a migration from the way the data is currently organized into a new way of doing it, which would definitely be out of scope for this ticket.
We could also try writing something that would separate the one string up into constituent pieces, but I'd estimate this would likely run into issues with the way people have formatted their addresses, used punctuation, etc. under the current system.
Do y'all have any thoughts for how to proceed with this?
Hi @JoshDevHub thank you bringing this to my attention and for detailed explanation. Before I make a final decision, I’m going to run this by design. Seeing that it would require a major change to how data is stored, I’m leaning toward sticking with one field but let me make sure with design first. I’ll be in touch!
@JoshDevHub go ahead and leave the address as one field. Thanks for checking and for pointing this out. Let us know if you need anything else :)
This issue has been inactive for 243 hours (10.13 days) and will be unassigned after 117 more hours (4.88 days). If you have questions, please
If you are still working on this, comment here to tell the bot to give you more time
This issue has been inactive for 363 hours (15.13 days) and is past the limit of 360 hours (15.00 days) so is being unassigned.You’ve just been unassigned from this ticket due to inactivity – but feel free to pick it back up (or a new one!) in the future! Thank you again for your contribution to this project.

