PR #997 fixed issue #701 for individual applications, but not for organization applications.
You can create a new organization application and save it as a draft, but when you try to save it as a draft again (before submitting it), there is a "server error" in the UI.
@frankduncan Looked into the problem and possible solutions and described them on zulip:
The issues is that the form binder for the Organization Disclosure Page performs a database query to see what agreements are available to the user. It does this each time the form is provided. The reason it does this is that we want to be able to look up to the full agreement, given only the ID coming in from the form request.
The problem comes in that hibernate is trying to flush the current session before querying the database. However, we've changed the working enrollment via the calls to all the form binders. That means that the current enrollment is out of date, and hasn't been saved, and so has a lot of transient fields. This causes an error.
The reason this doesn't happen in individual forms is that this query is only peformed for disclosures. That's the last page of the individual, and so there's no query to the database to figure out what's currently out there.
So, we have a few options:
1) Ignore, this is too much effort to go into, and just update the save as draft bug as "only fails for organizations". This is the least effort.
2) Change the form binders to have a update phase that we execute first. This is the second to most effort, but most bug ridden because if you are playing with them and forget this crucial step, you're going to run into this issue again.
3) Change the form binders to create new objects, having the necessary infromation in the forms to generate an entirely new document from the html request (no need to ping the DB to get the full information). This is the most effort, and I'm not actually sure is feasible.
4) Change the form binders to populate this necessary information on system bootup. This is the second least effort, but runs into the bug that if you change the agreements in the database while the system is running, you will run into issues.
5) just aggressively saving enrollments through each phase of the update. This would be a small bit of technical debt (would have to leave a comment saying that this is weird and we hacked it to avoid issue), but would be a one line change.
@frankduncan tried 5 and it did not work. So we went with 1 in PR #997. This issue is for follow-up work.
PR #997 fixed issue #701 for individual applications, but not for organization applications.
You can create a new organization application and save it as a draft, but when you try to save it as a draft again (before submitting it), there is a "server error" in the UI.
@frankduncan Looked into the problem and possible solutions and described them on zulip:
The issues is that the form binder for the Organization Disclosure Page performs a database query to see what agreements are available to the user. It does this each time the form is provided. The reason it does this is that we want to be able to look up to the full agreement, given only the ID coming in from the form request.
The problem comes in that hibernate is trying to flush the current session before querying the database. However, we've changed the working enrollment via the calls to all the form binders. That means that the current enrollment is out of date, and hasn't been saved, and so has a lot of transient fields. This causes an error.
The reason this doesn't happen in individual forms is that this query is only peformed for disclosures. That's the last page of the individual, and so there's no query to the database to figure out what's currently out there.
So, we have a few options:
1) Ignore, this is too much effort to go into, and just update the save as draft bug as "only fails for organizations". This is the least effort.
2) Change the form binders to have a update phase that we execute first. This is the second to most effort, but most bug ridden because if you are playing with them and forget this crucial step, you're going to run into this issue again.
3) Change the form binders to create new objects, having the necessary infromation in the forms to generate an entirely new document from the html request (no need to ping the DB to get the full information). This is the most effort, and I'm not actually sure is feasible.
4) Change the form binders to populate this necessary information on system bootup. This is the second least effort, but runs into the bug that if you change the agreements in the database while the system is running, you will run into issues.
5) just aggressively saving enrollments through each phase of the update. This would be a small bit of technical debt (would have to leave a comment saying that this is weird and we hacked it to avoid issue), but would be a one line change.
@frankduncan tried 5 and it did not work. So we went with 1 in PR #997. This issue is for follow-up work.