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.
• 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.

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, no flash error message would appear
• If the form got created, but no email was sent, the form would not get created.

[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]

shouldn't the email.laborStatusFormSubmitted be here?

[Kafui123]

Yes, the call is intentionally handled later in the flow. For overload forms, the email is triggered earlier on line 81 via email.LaborOverloadFormSubmitted(link) and for regular status forms, the emaila gets sent on line 91 after the FormHistory record is created.

[MImran2002]

Can I know the rationale for this as working on init.py file affect most of the backend

[Kafui123]

I added these lines to resolve a circular import issue where other files depended on the db instance from this file. At the time, those modules were being imported before the database had been properly initialized, which led to errors when accessing db. Importing the Flask app and initializing db with it ensured that the database instance was available when those modules were loaded.