Skip to content
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

feat: Team Settings Editor Form UI Changes #3305

Merged
merged 22 commits into from
Jun 25, 2024
Merged

Conversation

RODO94
Copy link
Contributor

@RODO94 RODO94 commented Jun 20, 2024

What is this PR?

Following on from previous PR: #3289 -- which added a new team_settings table to the database, this PR makes the relevant UI and Editor changes to interact with the new table. In addition, a new settings form is made so users can manage their own team settings.

  • Remove "commented out" validation on TeamSettings route view

@RODO94
Copy link
Contributor Author

RODO94 commented Jun 20, 2024

@DafyddLlyr Tried to update my branch to the latest main and accidentally pulled commits from you and Ian, is there a way to undo this?

I done a pull on main locally, ran a git merge main on feature branch, then git push...

It has worked previously.

Also, if it's not a problem, I'll do a git rebase main next time

@DafyddLlyr
Copy link
Contributor

@RODO94 I think running a rebase on this branch, then force pushing, should drop those commits 👍

If not, the simplest approach to fix this may be a new branch and cherry-picking your commits.

@RODO94 RODO94 force-pushed the rory/team-settings-editor branch from bdc928c to a6f4edd Compare June 20, 2024 14:28
Copy link

github-actions bot commented Jun 20, 2024

Removed vultr server and associated DNS entries

@RODO94 RODO94 force-pushed the rory/team-settings-editor branch from 41805bc to 63ca171 Compare June 24, 2024 10:24
@RODO94
Copy link
Contributor Author

RODO94 commented Jun 24, 2024

!! Worth noting that I have commented out the path validation check on the route to remove the permissions error, mostly for my mental health. This should be undone prior to squash + merge

@RODO94 RODO94 changed the title feat: Team Settings Editor Changes feat: Team Settings Editor Form UI Changes Jun 24, 2024
@RODO94
Copy link
Contributor Author

RODO94 commented Jun 24, 2024

Update: Altered PR title to focus only on Form UI components

Updated the PR title as I will break down the Editor changes into:

  • UI Components
  • Validation
  • Data Fetching
  • Error Handling + Component Changes

@RODO94 RODO94 marked this pull request as ready for review June 24, 2024 12:37
Copy link
Contributor

@DafyddLlyr DafyddLlyr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few small comments and suggestions, no show stoppers - looking good!

@@ -5,6 +5,7 @@ import React, { ReactNode } from "react";
const Label = styled(Typography)(({ theme }) => ({
flexShrink: 1,
flexGrow: 0,
width: "100%",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

It looks like this change has some unintended consequences in Design Settings where this component is also used.

@ianjon3s is going to take a wider review of these components and labels, so for now we could (temporarily) keep them inline, or use a repeated <Typography component="label" variant="subtitle2">

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another example I just hit -
image

editor.planx.uk/src/pages/FlowEditor/lib/store/user.ts Outdated Show resolved Hide resolved
</RadioGroup>
</InputRowLabel>
</InputRow>
<InputRow>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So actually I think we can remove this whole block! When we added this feature, we thought councils may want to have customisable URLs here, but so far this hasn't proved to be the case.

Here's my recommendation -

  • We keep these columns on the team_settings table, so if we need to customise this in future we easily can
  • We don't show this as a feature to the user, and see if we get any feedback
  • In future, we can easily add these form filed, or remove the db columns, based on feedback

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DafyddLlyr so remove this who file?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry - should have been clearer! Just the inputs for Planning Portal name and Planning Portal URL. We've found that nobody uses custom values here currently 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah okay! but keep the Boolean field and the homepage?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Asking because, as I am thinking, if it's just the Homepage + the Bool field, then what use is the bool field?

If it is just the Homepage, could I just incorporate that into the Contact Form?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Homepage should stay, and could move into contact 👍

Just taken a closer look at team_settings.has_planning_data - this looks like it's actually unused. We've recently moved this across to team_integrations (PR here - #2776)

What this means is -

  • We can remove the the form field for hasPlanningData - this is an integration, not a setting, and doesn't need to be handled here
  • We can remove the team_settings.has_planning_data column (in another PR)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies for not spotting this issue with has_planning_data sooner!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sick! All makes sense

</InputRow>
<InputRow>
<InputRowLabel>
Help Opening Hours
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit(ui/ux): I think we can remove the "Help..." prefixes from these labels - "Phone number", "Opening hours" and "Contact email address" feel like clearer / simpler labels.

There's always room for the data model and it's representation to the user to be different 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool!

What do you think about keeping the data model fields with the "help" prefix to group and indicate use?

Copy link
Contributor

@DafyddLlyr DafyddLlyr Jun 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I'd keep that internally, and just change the labels displayed to users 👍

Comment on lines 13 to 19
const formSchema = Yup.object().shape({
helpEmail: Yup.string()
.email("Please enter valid email")
.required("Help Email is required"),
helpPhone: Yup.string().required("Help Phone is required"),
helpOpeningHours: Yup.string(),
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DafyddLlyr maybe this is something we pick up with @ianjon3s as well, but in terms of UX copy and tone of voice in message handling, is there a particular way to write these error messages?

To ensure consistency in tone, I know people do like to manage how these a written

Copy link
Contributor

@DafyddLlyr DafyddLlyr Jun 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have standard copy for Editor-facing errors, but generally try to get input from the content team (+ Nomensa URs) on public-facing error messages.

I'm pretty sure most Editor-facing inputs just currently use .required() and would output whatever Yup outputs which would be something like ${fieldName} is required"helpEmail is required"

I think what you have here is great (${labelName} is required"Help email is required")

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@RODO94 RODO94 requested a review from DafyddLlyr June 24, 2024 14:46
Copy link
Contributor

@DafyddLlyr DafyddLlyr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect! Much smaller and neater with all those changes, thanks for working through them all.

@RODO94 RODO94 merged commit 9020589 into main Jun 25, 2024
12 checks passed
@RODO94 RODO94 deleted the rory/team-settings-editor branch June 25, 2024 09:14
@RODO94
Copy link
Contributor Author

RODO94 commented Jul 5, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants