-
Notifications
You must be signed in to change notification settings - Fork 2
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
Conversation
@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 It has worked previously. Also, if it's not a problem, I'll do a |
@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. |
bdc928c
to
a6f4edd
Compare
Removed vultr server and associated DNS entries |
41805bc
to
63ca171
Compare
|
Update: Altered PR title to focus only on Form UI componentsUpdated the PR title as I will break down the Editor changes into:
|
There was a problem hiding this 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%", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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">
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
editor.planx.uk/src/pages/FlowEditor/components/Settings/shared/SettingsForm.tsx
Outdated
Show resolved
Hide resolved
editor.planx.uk/src/pages/FlowEditor/components/Settings/GeneralSettings/newSettingsForm.tsx
Outdated
Show resolved
Hide resolved
editor.planx.uk/src/pages/FlowEditor/components/Settings/GeneralSettings/index.tsx
Outdated
Show resolved
Hide resolved
...r.planx.uk/src/pages/FlowEditor/components/Settings/GeneralSettings/HomepagePlanningForm.tsx
Outdated
Show resolved
Hide resolved
...r.planx.uk/src/pages/FlowEditor/components/Settings/GeneralSettings/HomepagePlanningForm.tsx
Outdated
Show resolved
Hide resolved
</RadioGroup> | ||
</InputRowLabel> | ||
</InputRow> | ||
<InputRow> |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 👍
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 👍
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 👍
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(), | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfect!
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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"
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this 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.
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.