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.

[MImran2002]

That is valid, there some local changes that I have to make to have the system up and running. But in those cases where usually it's the environment file unless explicitly stated by the issue i would keep it in the local change only instead of pushing it. So I am gonna go and revert it as pushing this through would not be compatible with other environment builds for other people. However, if its something that persists in your local change definitely save it on your end cause I have been in your situation and I saved mine in like a google doc.

[MImran2002]

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