Feat: Validate minimum of 2 hours/month for long-term mentor

[lauracabtay]

Description

• Create a validateMentorCommitment method that checks no month is < 2 hours for long term mentors.
• Call the method and mentorship service create and update method.
• Create relevant unit tests.
• Wondering if the check on months should be a bit more sophisticated (i.e. do we expect long term mentors to submit availabilities for a minimum of months in a row?)

Related Issue

Please link to the issue here

Closes #320

Change Type

• Bug Fix
• New Feature
• Code Refactor
• Documentation
• Test
• Other

Screenshots

Return 2xx for long term mentor with availability >= 2 hours:

Return 2xx for ad-hoc mentor with availability < 2 hours:

Return 4xx for long-term mentor with availability < 2 hours:

Pull request checklist

Please check if your PR fulfills the following requirements:

• I checked and followed the contributor guide
• I have tested my changes locally.

[dricazenck]

🚀

[dricazenck]

Wondering if the check on months should be a bit more sophisticated (i.e. do we expect long term mentors to submit availabilities for a minimum of months in a row?)

For long-term they don't submit months. So no need for check for the the months. The months are for ad-hoc sessions, usually long-term mentors should be available from the months of the cycle: April/November. But also flexible to discuss the availability with the mentee ;)

[dricazenck]

I notice a gap, in the mentor registration design, which is the number of mentees the mentor can accept in the cycle long-term.

For example:

"menteeSection": {
   "numMentee": 3,
    "mentorshipType": ["Long-Term", "Ad-Hoc" ],
    "availability": [ { "month": "APRIL", "hours": 2 },  {"month": "MAY",  "hours": 4 } ,  {"month": "JULY",  "hours": 5 }],
    "idealMentee": "string",
    "additional": "string"
  }

The attribute numMentee can help us to identify how many they can accept and also validate depending on the hours and months the are available. Which is the question you asked.

and This case for example would be invalid, because the mentor says can take 3 mentees, but he will be available for only 1 hour.

"menteeSection": {
   "numMentee": 3,
    "mentorshipType": ["Long-Term", "Ad-Hoc" ],
    "availability": [ { "month": "APRIL", "hours": 1 },  {"month": "MAY",  "hours": 3 } ,  {"month": "JULY",  "hours": 1 }],
  }

Or actually the best way would be to separated availability by Mentorship type:

"menteeSection": {
    "idealMentee": "string",
    "additional": "string",
   "LongTerm": { "numMentee": 2, "hours": 8 }, // Min 4 
    "AdHoc": [ { "month": "APRIL", "hours": 1 },  {"month": "MAY",  "hours": 3 } ,  {"month": "JULY",  "hours": 1 }],
  }

That will require migration and make the adjustments into the DTO and the queries, but I think would be a great improvement and give more context to mentorship team to know about the availability of the mentor, and also for the mentor, which will knows about the expectations in time and mentee.

Could you create this issue and if you are up to the challenge to pickup next? 🙈

[lauracabantoustaylor]

That sounds like a very good plan! Will create the issue tomorrow and yes, happy to pick it up next! 😄