Development: Create registration API about bridge-in-tech-backend

[mtreacy002]

Update:
Hi @anitab-org/bridgeintech-maintainers, So, I've managed to register to MS through calling its API from BIT Users service

Environment:
MS - Local server port: 4000; database name: local_data
BIT - local server port: 5000; database name: bit_schema

Now I'm in the process of creating BIT API using user_extension DAO and adding model to namespace.

I come across first issue.
It is difficult to achieve the Registration process as per what I want to achieve in the mockup where I need to add user_id into user_extension in BIT table at the same time as I create the user in the MS table. The reason is atm there's no way of finding the new user id unless the user has verified email and login (the only way to get it atm is using GET /user but it requires a token)

Can anyone help me with suggestion on how to get around this?

One of the solution I can think of atm is to have BIT POST /register taking the exact same input as per MS POST /register. Then when user first login, the first page they would see is the user's update profile page that they must fill in before they can go to their member homepage (since the values on the 2nd form (additional information) will determine their navbar type: with organization or without and time offset for dates related data).

Please feel free to share your thoughts.

[mtreacy002]

I see.... 😂. I've just opened my 1st PR to issue#19 😊. Hopefully that's ok (starting before the official coding phase starts 😀)

[ramitsawhney27]

@mtreacy002 your above suggestion seems fine. Please go ahead with that.

[ramitsawhney27]

@mtreacy002 please let me know if you have questions about this. cc: @isabelcosta

[mtreacy002]

Ok. Will work on it, @ramitsawhney27. But should I open a PR first to merge the code for the database schema and mock data I've done on issue#19?

[isabelcosta]

@mtreacy002 you will see a lot of issues like this coming up, but before this one it comes the one you already created #19 :) This is for the coding phase which has not started yet ;)

[isabelcosta]

All good @mtreacy002 :P

[meenakshi-dhanani]

According to my understanding, you want to register a user to BIT. Questions: When a user register to BIT, does it mean there are registered to MS too? For a user registered in MS, when that person logs in, does he/she have to register (new profile) to BIT or does he/she update BIT profile based on the pre-existing MS profile?

[mtreacy002]

The ideal answer is yes, user have one data for both BIT and MS. But it's not achievable in this GSoC. For now, the BIT user will login using the MS schema, which at initial stage of GSoC is going to be kept inside MS db. But at the later stage, we want MS and BIT to have the same DB end (one DB).
If the MS already have user data, and that user wants to also register with BIT, yes, then they need to add BIT related data on the BIT side. But this is not within GSoC scope. Atm, the initial Register is only for one way, that a new user is registering using BIT web app, which will keep their data in both MS and BIT schemas.

Does this answer your question?

[meenakshi-dhanani]

So for GSoc, we have two tables, one for BIT and one for MS. And post GSoC we make one table that can be the source of truth for all users? Is that correct?

[mtreacy002]

But if we make it as the option I mentioned in the previous post

One of the solution I can think of atm is to have BIT POST /register taking the exact same input as per MS POST /register. Then when user first login, the first page they would see is the user's update profile page that they must fill in before they can go to their member homepage (since the values on the 2nd form (additional information) will determine their navbar type: with organization or without and time offset for dates related data).

then, I think we'll cover both new or existing MS user (coz there will be no difference coz they both will be able to access BIT)

[mtreacy002]

So for GSoc, we have two tables, one for BIT and one for MS. And post GSoC we make one table that can be the source of truth for all users? Is that correct?

No, actually the tables are just one, but we have 2 schemas, BIT and MS.
In MS we have

• User
• Mentorship Relation
• Task List
• Task Comment

and in BIT we have

• user_extension
• personal background
• organization
• program
• mentorship_relation_extension

[mtreacy002]

Sorry... I'll explain to you further tomorrow. I need to get to sleep now, almost 2am here 😂

[meenakshi-dhanani]

Sure, please take care @mtreacy002

[meenakshi-dhanani]

Please take of validations at the API level, details of the validations are in here - anitab-org/bridge-in-tech-web#8

[mtreacy002]

Please take of validations at the API level, details of the validations are in here - anitab-org/bridge-in-tech-web#8

Can I confirm this. You mean we should do the validation on the Frontend UI, right? for backend, it needs to be done from the mentorship-system backend (need to open an issue and handle this backend validation there). Coz BIT is only using the MS API, but cannot alter the backend code. We can try to do it at BIT API level, but then it would still allow someone to bypass entering directly to MS API.
Ideally we should have 4 levels of validations, BIT UI, BIT API, MS API and MS UI. But if this is needed, then we just have to take care of it 😂.
For now (during GSoC), I'll cover the BIT UI and API then 😉