Ah.admin redesign

[huang0h]

Checklist

• 1. Run npm run check
• 2. Run npm run test
• 3. Change ClickUp ticket status to "In Review"
• 4. After making the PR, add PR link to ClickUp ticket

Why

Redesign the admin dashboard to consolidate admin features in one page

This PR

• Refactors the add site forms into a new page
• Move promote user/child account form into modals within buttons
• Add links to admin features under dashboard

Screenshots

Dashboard:

Promote user modal:

Child account modal:

Verification Steps

[chromium-52]

⛏️ Is this needed?

[huang0h]

🤦

[chromium-52]

💯

[chromium-52]

👍 lgtm!

[CerberusLatrans]

https://github.com/Code-4-Community/speak-for-the-trees-frontend/blob/6d989c4ad0953a217117f9571c3c5767ef7c8dab/src/containers/addSites/index.tsx#LL87C11-L87C11

This is defo just from my lack of understanding of the frontend, but why is there both an editsiteform and updatesiteform? I see that the request made upon UpdateSiteForm submission takes values from the editSiteForm except for plantingDate which comes from updateSiteForm -- are these all the values that cannot be changed via the UI?

Other than that, everything else is pretty clear to me. Great job on the redesign!

[huang0h]

https://github.com/Code-4-Community/speak-for-the-trees-frontend/blob/6d989c4ad0953a217117f9571c3c5767ef7c8dab/src/containers/addSites/index.tsx#LL87C11-L87C11

This is defo just from my lack of understanding of the frontend, but why is there both an editsiteform and updatesiteform? I see that the request made upon UpdateSiteForm submission takes values from the editSiteForm except for plantingDate which comes from updateSiteForm -- are these all the values that cannot be changed via the UI?

Other than that, everything else is pretty clear to me. Great job on the redesign!

Great questions! For the edit/update site forms, we have the "sites page" (you can access it at [base url]/site/[site id]), which is used to maintain site information. There's a difference between a site and a site entry - a site is the physical location of where a tree may go, so site-specific information includes address, latitude/longitude, etc. A site entry refers to what's actually at the site, namely the tree (if there is one) and information about it, such as species and status. If someone decides to replace the tree at a given site, we'd want to change the site entry information e.g. the species of the new tree, but since the site didn't change - it's still at the same place - we'd like to leave that be. The EditSiteForm is used to update site information, while the UpdateSiteForm updates site entry information (tbh they could be named better).
tl;dr we have two different forms because we're dealing with two different but related entities

As for the request, we actually do use all of the information from the update site form - note the '...request,' where we define the addSiteRequest. This is an example of JavaScript's spread syntax - in this case, we're using the spread syntax to take all of the key/value pairs from request and copying them into our new variable addSiteRequest. Finally, since we want to format the planting date in a specific way, we explicitly set the plantingDate again.

Hopefully this all makes sense - let me know if have any more questions!

[CerberusLatrans]

https://github.com/Code-4-Community/speak-for-the-trees-frontend/blob/6d989c4ad0953a217117f9571c3c5767ef7c8dab/src/containers/addSites/index.tsx#LL87C11-L87C11
This is defo just from my lack of understanding of the frontend, but why is there both an editsiteform and updatesiteform? I see that the request made upon UpdateSiteForm submission takes values from the editSiteForm except for plantingDate which comes from updateSiteForm -- are these all the values that cannot be changed via the UI?
Other than that, everything else is pretty clear to me. Great job on the redesign!

Great questions! For the edit/update site forms, we have the "sites page" (you can access it at [base url]/site/[site id]), which is used to maintain site information. There's a difference between a site and a site entry - a site is the physical location of where a tree may go, so site-specific information includes address, latitude/longitude, etc. A site entry refers to what's actually at the site, namely the tree (if there is one) and information about it, such as species and status. If someone decides to replace the tree at a given site, we'd want to change the site entry information e.g. the species of the new tree, but since the site didn't change - it's still at the same place - we'd like to leave that be. The EditSiteForm is used to update site information, while the UpdateSiteForm updates site entry information (tbh they could be named better). tl;dr we have two different forms because we're dealing with two different but related entities

As for the request, we actually do use all of the information from the update site form - note the '...request,' where we define the addSiteRequest. This is an example of JavaScript's spread syntax - in this case, we're using the spread syntax to take all of the key/value pairs from request and copying them into our new variable addSiteRequest. Finally, since we want to format the planting date in a specific way, we explicitly set the plantingDate again.

Hopefully this all makes sense - let me know if have any more questions!

That makes a lot more sense-- thanks for the thorough explanation. Just to be sure-- would it be correct to say that the onSubmitAddSite, though technically handling the UpdateSiteForm submission, is also submitting the values inputted in the EditeSiteForm (by retrieving them indirectly)?

[chromium-52]

👍 Quick comment but lgtm!

[chromium-52]

⛏️ this should be an unused interface that can be deleted (not sure why the linter didn't catch this tho)

[huang0h]

https://github.com/Code-4-Community/speak-for-the-trees-frontend/blob/6d989c4ad0953a217117f9571c3c5767ef7c8dab/src/containers/addSites/index.tsx#LL87C11-L87C11
This is defo just from my lack of understanding of the frontend, but why is there both an editsiteform and updatesiteform? I see that the request made upon UpdateSiteForm submission takes values from the editSiteForm except for plantingDate which comes from updateSiteForm -- are these all the values that cannot be changed via the UI?
Other than that, everything else is pretty clear to me. Great job on the redesign!

Great questions! For the edit/update site forms, we have the "sites page" (you can access it at [base url]/site/[site id]), which is used to maintain site information. There's a difference between a site and a site entry - a site is the physical location of where a tree may go, so site-specific information includes address, latitude/longitude, etc. A site entry refers to what's actually at the site, namely the tree (if there is one) and information about it, such as species and status. If someone decides to replace the tree at a given site, we'd want to change the site entry information e.g. the species of the new tree, but since the site didn't change - it's still at the same place - we'd like to leave that be. The EditSiteForm is used to update site information, while the UpdateSiteForm updates site entry information (tbh they could be named better). tl;dr we have two different forms because we're dealing with two different but related entities
As for the request, we actually do use all of the information from the update site form - note the '...request,' where we define the addSiteRequest. This is an example of JavaScript's spread syntax - in this case, we're using the spread syntax to take all of the key/value pairs from request and copying them into our new variable addSiteRequest. Finally, since we want to format the planting date in a specific way, we explicitly set the plantingDate again.
Hopefully this all makes sense - let me know if have any more questions!

That makes a lot more sense-- thanks for the thorough explanation. Just to be sure-- would it be correct to say that the onSubmitAddSite, though technically handling the UpdateSiteForm submission, is also submitting the values inputted in the EditeSiteForm (by retrieving them indirectly)?

Yep, I'd say that's a good way of thinking about it!