It might be that other implementors would like it work like this always as well. OTF at one point thought it vital that it could not be changed but we can ask @fourthletter how they stand on this today.

I assume you have noticed that determinations has a check if a dismiss/accept determination exist and in that case assumes no more determination should be created. This needs to be handled as well.

Maybe the lock should go in effect only after a project has been created? @fourthletter What do you think?

A 'revert back' function from the final stage needs to consider:

1. A record of activity or action that is transparent to both the applicant and funding organization (ie Activity Feed)
2. When a concept note has been approved, a proposal will be generated in a 2-stage application process. Reverting back means resolving for this as well.

There is currently a stage 'Accepted but additional approval required' before the final stage that enables staff to revert back. It's a holding area while the application goes through compliance and finance review. It's a function that definitely needs more UX love.

Finally able to circle back on this!

The reasoning from our users is that there are a number of reasons (contract negotiation, etc) that can cause a previously accepted (or denied) determination to end up not being fulfilled. So what to do in that case?

The solution we coded up only added new transitions to the workflows, so extra communication is handled outside of hypha. I'm not sure how many of the edge cases are intrinsically handled by that.

If it's fundamental to hypha that determinations not be undone, my guess is that this will transition into us doing workflow extension/modification outside of changing hypha/apply/funds/workflow.py

I think, given the feedback here, I've got a pretty good idea of what edge cases to start making sure our code accounts for. But is this a feature base hypha wants? Or conditionally wants based on configuration?