-
Notifications
You must be signed in to change notification settings - Fork 38
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
Project Form/SOW workflow can be confusing #4204
Comments
Do OTF still require them to be separate forms? The reson for the SOW was I believe to have a subsection of the PAF that a separate group of people needed. This people did not need or should see the other parts of the PAF, like names, addresses etc. We merged them since staff then did not want to add things in two separate forms. If OTF still needs the separate SOW we should make it easier to edit. If they do not we can removed the features, I'm pretty sure no one else has any use of it. |
ah okay that makes sense. OTF does still utilize them as separate forms for the time being - maybe that could be a configurable option in wagtail though to combine the two? |
even when combined though does it still make sense to have the SOW be it's own "line" if it's intended to be a subsection of the PAF? |
I believe OTF want the option to view the SOW separately, download it as a PDF etc. |
@frjo yeah that should be kept but if other implementers wanted to configure the SOW to be a subsection of the PAF it makes sense to me that we wouldn't show it as separate in that use case? but if y'all have heard different from the adopters then that works fine for me. |
I do not think anyone else is going to use a SOW form at all. OTF use case is quite specific. Most likely have no need for a project form at all. |
ahh alright that makes sense, so maybe just keep it separate if an SOW exists? I can take a stab at that if so |
Adding an edit link to the SOW makes sense I think. Could be as easy as a link to the current PAF edit form that scrolls down to the SOW part. If it makes more sense to OTF we can also add a separate SOW edit form. The question is then if it also should show when staff edit the PAF. Whatever makes sense to staff. |
Fixes #4204. Moves the SOW out into it's own form when editing. This also removes the `user_has_updated_details` attribute in favor of using a property for both the project form & SOW that checks the field_data on the respective form. This allows for tracking of the project form & SOW independently. Also a few small aesthetic changes bundled in, like margin additions & hiding of submission attachments sidebar when there's none. --------- Co-authored-by: Fredrik Jonsson <[email protected]>
When a Project Form & SOW exist on a fund, populating them in Hypha can be a bit confusing. From my experience, both are initially populated under
Project Form
. Once you selectFill in
, you first populate the Project Form then the SOW immediately under it. Once you pressSave
, that's when the SOW field will appear underProject Documents
. But, to edit it the user needs to select edit onProject Form and scroll back down
before filling in PAF/SOW

after hitting save while editing

Project Form
I'm not sure if there's context I'm missing or if this is a bug but to me it'd make more sense to have the SOW be it's own line from the start, rather than having to go through Project Forms to edit it.
The text was updated successfully, but these errors were encountered: