-
Notifications
You must be signed in to change notification settings - Fork 39
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
Add server side previews to the application workflow #3725
Conversation
Do we really need a configuration option. I would suggest keeping it as default for all the rounds/labs. One less configuration to care about. |
This look like a nice implementation! I would also prefer no option to make it more simple. We can ask the other implementors and if some have really strong opinopn on it we might add a global env var to turn the previews off. I can not see an organisation that wants previews for some fund/lab but not all. |
Thanks @frjo @theskumar, this was great feedback! After chatting today in the maintainers meeting it seems like the path forward is global configurations for the previews rather than per-fund/lab as OTS brought up that some organizations might not want this feature. Will have those changes up soon! |
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.
This works really well in my testing. One small comment around the new env setting.
There is also an issue for sites that set:
FORCE_LOGIN_FOR_APPLICATION = False
The applicant fill in the submission form as anonymous (not logged in) and click "Preview and submit". They then have the option to click "Submit for review" or "Edit". Both will take them to the login screen without any explanations.
An account is created for them and the e-mail is sent out but we do not communicate this fact to them in Hypha.
If you set:
REQUIRE_PREVIEW = False
You still have the same issue if the applicant click the optional "Preview" button.
How should we handle this?
A simple way would be to make preview only work for logged in users.
@frjo thanks for testing! This is definitely an oversight from me, I'll go back to the drawing board for this one.
I think this would also negate |
@wes-otf I think the best solution is to only activate previewing for logged in users (regardless if We then document that What do you think? |
@frjo Yeah I think that is the only answer that really makes sense. All the options I can think of would either be a major overhaul or a potential security vulnerability |
This should be all set now! |
@frjo I just created two labels for user testing vs dev testing. Let me know if you think that makes sense moving forward |
* main: User with Staff role can approve contracts (#3736) Add server side previews to the application workflow (#3725) Move cookieconsent settings to generic settings (#3722) Remove public "standard_pages" app (#3721) Remove public "funds" app (#3720) Update github actions. (#3740) Remove public "forms" pages app (#3719) Remove public "projects" app (#3718) Remove "people" app (#3739) Remove public "partners" app (#3716)
## Description Closes #3545. This creates the option to require a user to preview their form before submitting it. The requirement is set on a per fund/lab basis, and is a ~required checkbox when the lab/fund is configured in Wagtail admin~ global Django configuration option. The preview first saves the application as a draft, then presents the user with a preview of their application. Upon viewing, the user can either edit or submit as seen in the flow diagram below.
## Description Closes #3545. This creates the option to require a user to preview their form before submitting it. The requirement is set on a per fund/lab basis, and is a ~required checkbox when the lab/fund is configured in Wagtail admin~ global Django configuration option. The preview first saves the application as a draft, then presents the user with a preview of their application. Upon viewing, the user can either edit or submit as seen in the flow diagram below.
## Description Closes HyphaApp#3545. This creates the option to require a user to preview their form before submitting it. The requirement is set on a per fund/lab basis, and is a ~required checkbox when the lab/fund is configured in Wagtail admin~ global Django configuration option. The preview first saves the application as a draft, then presents the user with a preview of their application. Upon viewing, the user can either edit or submit as seen in the flow diagram below.
Description
Closes #3545.
This creates the option to require a user to preview their form before submitting it. The requirement is set on a per fund/lab basis, and is a
required checkbox when the lab/fund is configured in Wagtail adminglobal Django configuration option. The preview first saves the application as a draft, then presents the user with a preview of their application. Upon viewing, the user can either edit or submit as seen in the flow diagram below.Sloppy Flow Diagram:

Screenshots:


Test Steps
Testing preview on initial apply
Apply
on any fund in the listPreview and submit
appears at the bottom of the applicationPreview and submit
buttonSubmit
andEdit
buttons at the bottom.Submit
successfully submits the submission (can be verified by using the navigation bar to go toSubmissions
>All submissions
.Testing preview on edit
Apply
on any fund in the listSave Draft
button at the bottom of the pageYour application is saved as a draft.
, select theContinue editing
button.Preview and submit
button is present at the bottom of the page.Preview and submit
buttonSubmit
andEdit
buttons at the bottom.Submit
successfully submits the submission (can be verified by using the navigation bar to go toSubmissions
>All submissions
.