526 contrasting confirmation messages

[Kafui123]

Fixes issue #526

Changes:

• Fixed the issue where an error message was shown, but a successful flash confirmation still appeared afterward. Now the feedback is consistent... no mixed signals for the user. Flash message errors are considered and both back-end error and front-end error UI are done fro both developers and users.
• Adjusted the logic so that success and failure states are clearly separated and reported correctly, instead of overlapping or triggering both paths.
• Addressed the case where email sending could fail, but the form would still be created, which previously caused a misleading failure message even though the form existed.
• Ensured that form creation and email sending happen within a single transaction block.
• Front-end flash message is more responsive, stacked

Testing:

• Click on administration and then manage terms.
• Select a valid term under any academic year.
• Create a new labor status form and then click submit
• If everything succeeded, flash success message would appear
• if you want to break it and see an error flash, you can remove a parameter for one of those functions that send an email to see the error: createOverloadFormAndFormHistory , emailDuringBreak(checkForSecondLSFBreak
• If the form got created, but no email was sent, the form would not get created and an error flash will appear.

[bakobagassas]

Why are we changing 6 test files ? I don't think most of those changes are necessary

[Kafui123]

Why are we changing 6 test files ? I don't think most of those changes are necessary

I had to make those changes because they(the test files) were failing as a result of the new changes I added.

[Arohasina]

Your tests now handle success cases, but could you consider adding an integration test for partial/full submission failure scenarios after you have added the fixes mentioned above?

[Kafui123]

Your tests now handle success cases, but could you consider adding an integration test for partial/full submission failure scenarios after you have added the fixes mentioned above?

Your tests now handle success cases, but could you consider adding an integration test for partial/full submission failure scenarios after you have added the fixes mentioned above?

Your tests now handle success cases, but could you consider adding an integration test for partial/full submission failure scenarios after you have added the fixes mentioned above?

Since the main change in this pr was to put everything inside a mainDB.atomic block so that a form would not get submitted if email sending fails i do not think that it would be necessary testing the mainDB.atomic() block since that is peewee's behavior.

[Arohasina]

looks good !

[MImran2002]

there are whitespaces, some changes I will revert to reduce the code change scope that are not related to the issue description