Create DAO and New Endpoints for New Program Mentorship Relationship

[decon-harsh]

Is your feature request related to a problem? Please describe.
Create DAO and New Endpoint so that a mentorship relationship can be created b/w Program , Mentor and Mentee.

Describe the solution
I will create a DAO and new endpoints, that will allow creating a mentorship relation b/w Program, Mentor & Mentee.
Following this gist1 & gist2

[decon-harsh]

@mtreacy002

Now we are using Program.end_date as end_date_datetime (See line 17 of this gist) instead of taking the end date from the mentor itself.

I should remove these constraints?

[mtreacy002]

@decon-harsh , can you please follow the issue template in particular the first two sections ("Is your feature request related to a problem?" and "Describe the solution you'd like")? The other 2 sections of the template can be optional.

Now we are using Program.end_date as end_date_datetime (See line 17 of this gist) instead of taking the end date from the mentor itself.

We have to remember the difference in the BIT and MS mentorship relation:

• MS mentorship relation is not involving a program, so the mentoring relation duration is agreed between mentor and mentee within the max and min set by the system.
• BIT mentorship relation is involving a program, so the mentoring relation duration is set by the program

I suggest to keep mentorship_relation.py DAO untouched so that Mentorship System can function as intended independent of BIT. You just need to create a separate DAO "mentoring_program_relation.py" for BIT call that will take the Program.end_date as the end_date (ignoring the max and min time constraint for mentoring relation of Mentorship System). Does this make sense? PS: please create a separate file for this BIT call under app/api/resources and app/api/model for clarity. This way developer can see a different section on Swagger UI if they want to check API endpoints relevant to BIT on MS backend.

[decon-harsh]

@decon-harsh , can you please follow the issue template in particular the first two sections ("Is your feature request related to a problem?" and "Describe the solution you'd like")? The other 2 sections of the template can be optional.

Now we are using Program.end_date as end_date_datetime (See line 17 of this gist) instead of taking the end date from the mentor itself.

We have to remember the difference in the BIT and MS mentorship relation:

• MS mentorship relation is not involving a program, so the mentoring relation duration is agreed between mentor and mentee within the max and min set by the system.
• BIT mentorship relation is involving a program, so the mentoring relation duration is set by the program

I suggest to keep mentorship_relation.py DAO untouched so that Mentorship System can function as intended independent of BIT. You just need to create a separate DAO "mentoring_program_relation.py" for BIT call that will take the Program.end_date as the end_date (ignoring the max and min time constraint for mentoring relation of Mentorship System). Does this make sense? PS: please create a separate file for this BIT call under app/api/resources and app/api/model for clarity. This way developer can see a different section on Swagger UI if they want to check API endpoints relevant to BIT on MS backend.

Yes I am creating a new DAO and for this I copied the skeleton code of normal create request method and then modified things. Can I ask one more thing can a program send request to mentee first and then mentor? And Can Mentee send a request to program first?

[mtreacy002]

can a program send request to mentee first and then mentor?

@decon-harsh , the program rep can send the request to user regardless of their role , so it can be either to mentor first then mentee, or to mentee first then mentor. The 1st scenario in the first gist is an example program send request to mentor first. But the logic should allow either of them to be first.

Can Mentee send a request to program first?

yes, the same applies here, the logic should allow either of mentor or mentee to apply to program first.

Since this is quite a big issue, would you like me to divide this task into 2 subtasks, one for when program send request to a mentor/mentee, the other task can be for when a mentor/mentee send request to a program. Because either ways, you would have to create a separate API endpoint for each one of these tasks.
You can choose either one to focus on this issue (just modify the issue title and description accordingly so we know which one you're going to work on for now. I will open a separate issue to give other contributor a chance to work on it too. What do you think?

[decon-harsh]

@mtreacy002 no i am good , as this is a big task , i might be troubling you with some more questions. 😁 , bear me please 🙏

I am quite excited to solve this issue.

Update: Almost done (Program sends request to mentor or vice versa)

[mtreacy002]

@mtreacy002 no i am good , as this is a big task , i might be troubling you with some more questions. 😁 , bear me please 🙏

I am quite excited to solve this issue.

That's ok, I'm excited myself to see how this will unfold. Ask me anything anytime, I would be happy to brainstorm with you 😉.

[decon-harsh]

@mtreacy002 Update:

Currently made a DAO and two endpoints(one to send initial request and one to accept it ), email logics. For now ,

1. Program can send initial request to a mentor/mentee.
2. Mentor/Mentee can send initial request to a program. (both through a single endpoint)

Database instance gets created, following the gist.
Validations are checked.

Then mentor/mentee/org_rep_user can accept it.

Moreover, as this is a cross project issue I am trying to minimize the code spread(i.e making more endpoints or DAO)

Now I will create an endpoint that will take mentorship_relation id (as a parameter) and mentor/mentee_id (through request body) and then extend the relation (the second part).

I am looking forward to complete this in a day or two.

[mtreacy002]

@mtreacy002 Update:

Currently made a DAO and two endpoints(one to send initial request and one to accept it ), email logics. For now ,

1. Program can send initial request to a mentor/mentee.
2. Mentor/Mentee can send initial request to a program. (both through a single endpoint)

Database instance gets created, following the gist.
Validations are checked.

Then mentor/mentee/org_rep_user can accept it.

Moreover, as this is a cross project issue I am trying to minimize the code spread(i.e making more endpoints or DAO)

Thanks for the update, @decon-harsh 👍

Now I will create an endpoint that will take mentorship_relation id (as a parameter) and mentor/mentee_id (through request body) and then extend the relation (the second part).

Please make sure to keep BIT relevant task on BIT backend side (like this next one to create the mentorship_relation_extension instance from bitschema should be done through adding BIT DAO not MS DAO).
So, the starting point of this logic (sending initial request to create a mentorship program relation) should be at BIT backend by taking relevant input from the user (to create the Mentorship_relation and the MentorshipRelationExtension instances), then making internal call to MS endpoint you've just created and get the new mentorship_relation id as the response. From there you can continue with the BIT logic (without user having to send another api request) to create the mentorship_relation_extension using this next BIT DAO you're going to create. At the end of the logic, you'll have the first flow of sending initial request and created the 2 instances you need for mentoring program relation.
The next logic is for the other party to accept the request.
Let me know if you have doubt on this point.

I am looking forward to complete this in a day or two.

take your time, just keep me updated on your approach just like what you've done here 👍.

[mtreacy002]

PS: to test the first flow as I described above, you need to use the existing issue # 161 with PR # 185 to create the relevant logic. We will test this feature (sending initial request for mentoring program relation) by running this PR branch as MS backend server and the relevant BIT backend PR branch as BIT backend server.

[decon-harsh]

Please make sure to keep BIT relevant task on BIT backend side (like this next one to create the mentorship_relation_extension instance from bitschema should be done through adding BIT DAO not MS DAO).
So, the starting point of this logic (sending initial request to create a mentorship program relation) should be at BIT backend by taking relevant input from the user (to create the Mentorship_relation and the MentorshipRelationExtension instances), then making internal call to MS endpoint you've just created and get the new mentorship_relation id as the response. From there you can continue with the BIT logic (without user having to send another api request) to create the mentorship_relation_extension using this next BIT DAO you're going to create. At the end of the logic, you'll have the first flow of sending initial request and created the 2 instances you need for mentoring program relation.
The next logic is for the other party to accept the request.
Let me know if you have doubt on this point.

@mtreacy002
Yes, that is my plan. I submitted a rough PR for MS DAO and Endpoints. Please have a look .

I will start working on the BIT part asap!