Skip to content

Conversation

@glenblosser-nava
Copy link
Collaborator

Summary

Work for #5931

Changes proposed

Adds conditional rendering to the save button, reliant on the application's status not being submitted or accepted

Context for reviewers

#5931

Validation steps

Submit an application in a dev environment, and verify that the save button disappears

async function FormPage({ params }: formPageProps) {
const { applicationId, appFormId } = await params;
const { data, error } = await getFormData({ applicationId, appFormId });
let details = {} as ApplicationDetailsCardProps;
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This block is copied from the top-level application page, using the same logic to fetch the application information

@glenblosser-nava glenblosser-nava changed the title 5931 ready for review [Issue #5931] Hide save button when application is submitted Oct 28, 2025
Copy link
Collaborator

@doug-s-nava doug-s-nava left a comment

Choose a reason for hiding this comment

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

works correctly! a couple minor requests and things to think about

* @mdragon # project lead

/documentation/ @acouch @andycochran @btabaska @chouinar @doug-s-nava @joshtonava @mdragon @myduong-navapbc @widal001 @prasnava @jakobpederson @ErinPattisonNava @glenblosser-nava # everyone
/documentation/ @acouch @andycochran @btabaska @chouinar @doug-s-nava @joshtonava @mdragon @myduong-navapbc @widal001 @prasnava @jakobpederson @ErinPattisonNava @glenblosser-nava @brianlee-nava # everyone
Copy link
Collaborator

Choose a reason for hiding this comment

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

github is saying that @brianlee-nava may not exist or have access to the project. Certainly seems like the user exists, can we confirm access?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'll double check. He asked me to add him to the codeowners list since I was doing a PR anyway

Copy link
Collaborator

@doug-s-nava doug-s-nava Oct 31, 2025

Choose a reason for hiding this comment

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

also wanted to make sure that @brianlee-nava knows what he's signing up for here - any time a PR comes out with an update to documentation he'll be pinged with an email for a review. I'm all for that if he wants to contribute that way, but since none of the other PMs are in the list, wanted to check

Copy link
Collaborator

@doug-s-nava doug-s-nava 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 notes on approach for read only widgets, happy to talk it through

name={id}
required={required}
disabled={disabled}
disabled={disabled || readonly}
Copy link
Collaborator

Choose a reason for hiding this comment

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

this approach means each widget needs to implement disabling fields based on the "readonly" prop individually. Since each field (except in the budget form) is rendered through the "renderWidget" function, and each widget takes a "disabled" prop, we could do this calculation there instead, and pass "disabled: true" from "renderWidget" into each widget whenever "readonly" is true. We'd still have to figure out the budget form, but this should handle every other widget type without touching the individual widgets themselves

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This approach was copied from our other widgets, I can change it if need be. I've gone ahead and had formFields pass both readonly and disabled to its children to simplify future implementation

Copy link
Collaborator

Choose a reason for hiding this comment

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

not sure what you mean about copying from other widgets. My concern is that this way each widget needs to interpret readonly separately when we could potentially isolate that logic in the widget renderer. Maybe we can get on a call to show you what I'm thinking?

Copy link
Collaborator

@doug-s-nava doug-s-nava left a comment

Choose a reason for hiding this comment

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

Want to make sure we're on the same page on where to calculate the disabled props before I approve, but this all works! nice job.

* @mdragon # project lead

/documentation/ @acouch @andycochran @btabaska @chouinar @doug-s-nava @joshtonava @mdragon @myduong-navapbc @widal001 @prasnava @jakobpederson @ErinPattisonNava @glenblosser-nava # everyone
/documentation/ @acouch @andycochran @btabaska @chouinar @doug-s-nava @joshtonava @mdragon @myduong-navapbc @widal001 @prasnava @jakobpederson @ErinPattisonNava @glenblosser-nava @brianlee-nava # everyone
Copy link
Collaborator

@doug-s-nava doug-s-nava Oct 31, 2025

Choose a reason for hiding this comment

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

also wanted to make sure that @brianlee-nava knows what he's signing up for here - any time a PR comes out with an update to documentation he'll be pinged with an email for a review. I'm all for that if he wants to contribute that way, but since none of the other PMs are in the list, wanted to check

schema: RJSFSchema;
uiSchema: UiSchema;
formContext?: RootBudgetFormContext;
readonly?: boolean;
Copy link
Collaborator

Choose a reason for hiding this comment

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

sry to not have mentioned this earlier - can we change this to readOnly for camelCase consistency?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Got it

name={id}
required={required}
disabled={disabled}
disabled={disabled || readonly}
Copy link
Collaborator

Choose a reason for hiding this comment

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

not sure what you mean about copying from other widgets. My concern is that this way each widget needs to interpret readonly separately when we could potentially isolate that logic in the widget renderer. Maybe we can get on a call to show you what I'm thinking?

console.error(`Unknown widget type: ${type}`, definition);
throw new Error(`Unknown widget type: ${type}`);
}
if (props.isFormLocked) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

thanks for making this change - with this in place I think you can roll back the readOnly changes to each of the individual widgets other than the ones that weren't already handling disabled field states (which I think is the attachment widgets and budget form widgets)

@doug-s-nava
Copy link
Collaborator

split "readonly / disabled" into its own ticket #7067

glenblosser-nava added a commit that referenced this pull request Nov 17, 2025
## Summary

Work for #5931

## Changes proposed

When the form is not in progress, the Save button is hidden
This PR includes work that will be implemented in a future PR for #5931

## Context for reviewers

This PR is part of larger work on the #5931 ticket, but _only_ features
the hidden save button change. The readonly changes are also present in
[this](#6870) PR.

## Validation steps

After submitting an application, the Save button should not be visible
on forms.

---------

Co-authored-by: Glen Blosser <[email protected]>
@doug-s-nava
Copy link
Collaborator

@glenblosser-nava can we close this PR at this point or are you going to come back to it for the disabled fields?

@doug-s-nava doug-s-nava reopened this Nov 24, 2025
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.

3 participants