feat: Email notifications for new likes, matches and messages

[pranavbalakrishnan4100]

Addresses #342

• Added a new entity UserSettings to User.java
• Added unified endpoint for all three user preferences under user settings .
• Created new email templates for all three cases.
• Added necessary test cases.

Opened a ticket in alovoa-expo to handle necessary front end changes.

[Nonononoki]

You need to remove the apache-maven folder

[pranavbalakrishnan4100]

Removed apache-maven folder.

[Nonononoki]

1. .gitignore has 1 unneeded extra line
2. Why have you added mysql dependencies?
3. UserController has a bunch of code commented out

[pranavbalakrishnan4100]

Latest changes updated.

Added mysql dependency to run using mysql in my machine. Removed it now.

[Nonononoki]

Please do not change .gitignore, place maven outside of the project instead. Looking good otherwise.

[pranavbalakrishnan4100]

Latest changes updated. Please have a look and approve.

[Nonononoki]

In UserController, please separate all 3 mail settings into individual endpoints. Also, please use PostMapping instead of PutMapping, something like @PostMapping(value="/settings/update/emailLike/{value}") (see updateUnits()). Also consider creating a separate Controller class for the UserSettings alone.

[Nonononoki]

Member variables of UserSettings should all be private and should be used with a getter/setter.

[Nonononoki]

After some thought, the emailMatch should be scrapped.
The user who gives the like that leads to a match should not receive the match email.
The user who gets the like should either get a like email OR a match email, but never both at the same time.

[pranavbalakrishnan4100]

My thought process behind the unified endpoint was that we might want to have the user settings page as a form. The form will have all the three values set as false when initialised. Whenever a user makes a change to one or more of these settings, we can once again create a UserSettings object with the new values and make the request.

If you insist on changing it, I can go ahead and do it.

[Nonononoki]

It's better to separate them.

[pranavbalakrishnan4100]

I've made the changes as discussed above. Kindly take a look at the UserSettings controller and let me know if its okay to directly update the email settings as I've done. Or do I need to create a seperate UserSettingsService and create a new method to do this?

[Nonononoki]

Spotted a few more issues:

• Rest end point shoud be "/user/settings" and not "/user-settings"
• UserSettingsController is completely wrong, new settings isn't being saved to database. Also RestController classes shoudn't have any logic in them, please create a new UserSettingsService
• testUpdateUserSettings in UserServiceTest.java doesn't test anything at all. Please add tests for the new UserSettingsService and create a UserSettingsServiceTest instead of using the already bloated UserServiceTest

I just made a new commit for adding UserPrompt, you can use it as reference: 4f0ca1c

[pranavbalakrishnan4100]

Hopefully the changes are fine now. Sorry to keep this going back and forth.

[pranavbalakrishnan4100]

@Nonononoki I had a query that I was hoping you could answer.

Why do you insist on using @PostMapping instead of @PutMapping even when the api requests is specifiically an update operation? This seems to be pretty consistent across the codebase.
In the commit you have referenced above you seem to have used @PostMapping for delete operations as well? Was that intentional?

[Nonononoki]

It's just semantics. I feel like there should be only 2 types of requests, you want something from the server (get) and you want the server to do something for you. In which case I opted for post. Might not be right, but cleaner imo.

[pranavbalakrishnan4100]

Sure. Thanks for clarifying.

…

On Fri, 16 Feb 2024 at 5:53 PM, Nho Quy Dinh ***@***.***> wrote: It's just semantics. I feel like there should be only 2 types of requests, you want something from the server (get) and you want the server to do something for you. In which case I opted for post. Might not be right, but cleaner imo. — Reply to this email directly, view it on GitHub <#356 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN5QGCDZYPNRWAETJ4VJEETYT5FUJAVCNFSM6AAAAABDBOIEROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBYGI4TENJRG4> . You are receiving this because you were assigned.Message ID: ***@***.***>