Feature/stepper refinement

[EdoStorm96]

So I went a bit ham ... I think I've made some nice improvements to the stepper. It seems to work well, but I'm curious to hear your thoughts, @miggol.

I am now a lot more intimate with the new stepper, and also more appreciative of its utility. Kudos again :)

So, what I've done:

• Firstly, I did get rid of the stepper for the first form page. This allowed me to simplify quite a bit, because the stepper is always working with a proposal of which the type is known. This is chill imo.
• I've implemented the flows for the different proposal type (PreAss and PreAppr, as I refer to them.)
  • I've messed a lot with the WMOChecker ...:
  • Firstly I noticed that the WmoApplicationForm (different from WMOUpdate and such) was not implemented in the stepper, so I've incorporated that. (fixes #699)
  • I've also done some work on the Wmo views and forms themselves, as I found some incorrect urls ...
  • I also figured I could make the WmoChecker into a ModelFormChecker, to also get rid of the WmoItem. This was quite the hassle ... I initially wanted to use an CreateOrUpdateChecker, but this did not quite work, so I took inspiration and made it into its own design. This seems to work fine now. However, I do think we need to look into the clean()'s of WMO related forms as these seem kindoff incomplete ...
  • So then the big one, I've overhauled the validation. (fixes #693) This was pretty simple luckily! A few bumps on the road:
  • many forms need form kwargs, so the ModelFormChecker now has a get_form_kwargs() method.
  • Then the other big thing: as individual sessions and tasks are not incorporated into the stepper (which I still think is good) these needed their own validation function. This is somewhat akin to the old validation system, but quite a lot simpler. I don't hate it.
  • To my great frustration, #691 still persists. I don't know 😭 ....
  • Lastly I've made some simple implementations to get the correct css classes (incomplete, complete and disabled) This works ... but I feel like there might still be some bugs ... I think having this, mostly just really showcases inconsistencies/messiness in form's individual validation ... So it would be good to have a look at that ... (fixes #694, #693)

Sorry for the big PR ... One thing led to another and such. But overall I think this has improved the stepper quite a bit!

[EdoStorm96]

Ok, So I've adressed your comments ... I guess this is fine for now, although I don´t love some aspects of the current design ... Mainly the validation of sessions and tasks ;p A small overview of what I've done:

• ensure disabled items are no longer elements
• ensure ContainerItems check all their children and represented errors thusly.
• Mostly removed ContainerItems from the stepper, so that all major steps represent modelforms and the modelform's errors. ContainerItems are now only used for studies, when there are multiple studies.
• This also led to some slight reordering. It used to be:
  • StudyEnd > TranslatedForms > Documents > DMP But now it's:
  • StudyEnd > Documents > TranslatedForms > DMP
• Improved the working of validation and (mostly ...) moved it inside of the stepper. I have mixed feelings about this, as this also leads to a lot more imports on stepper.py. But maybe you have suggestions for improvements of Stepper.get_form_errors() ... I did ensure all the problems with validation you pointed out are fixed ... But this also made the design a bit more complicated.
• I've added a possibility of providing a get_checker_errors function to ModelFormItem's in case we need to provide some more specific validation. I've implemented this on SessionsChecker, as an example.
• And we're (for now) still stuck with this custom validator function for sessions and tasks ... Which gets called everytime the stepper gets rendered, just to give the Sessions stepper item the right color ... :skull:

IMO this is fine for now though. Curious to hear your thoughts :+1: