Use actual data of Designers/PMs/HRs instead of mock data

[pallabez]

• [ ] Decide how we are separating designers, developers and in future product managers
• [ ] Update user data in backend accordingly and update API contracts for it.
• [ ] Use actual data in members page.

[ganshul34]

@pallabez Can you please confirm if anyone has already started working on this issue?

[pallabez]

Nope. Would you like to take this up?

[ganshul34]

Sure @pallabez. Let me first start with understanding the current workflow and then I'll propose the relevant changes.

[ganshul34]

@pallabez Following are the changes that I am proposing

Problem Statement Currently, Under Members Tab, we have a List of all the People, separated by Designers, Members and New members. Currently, the Designer's data is mocked.

• We need to set up a relationship between users and these professional tags and eventually remove the mocked data.

Assumptions:

1. A user can have multiple professional tags (One to Many Relationship).
2. Only Super User can add these professional tags.
3. A user having relevant permissions can toggle these tags for itself.
4. We can provide an interface where superusers can add/delete(Soft delete) these tags (Maybe).
5. Initially add a collection in DB through a script and will write a CRUD API to alter the collection in the future.

Collection Name - professional_tags User field name - profession_tags type : Object

[pallabez]

Why not call it tags or maybe use the existing roles field? That way we can let them have access to API based on their roles

[ganshul34]

Hey @pallabez

Currently the roles are exported from a constant file, so we need to store these roles (these will be default roles ) in the roles collection in the database (These will be default roles).

We can use this roles collection to store the tags / professional_tags based on the following assumptions.

Assumptions:-

1. A user can have multiple default roles (A user can have SUPER_USER role simultaneously with MEMBERS and APP_OWNER role).
2. Similarly, the user can have the SUPER_USER role with the DEVELOPER, DESIGNER role.

Where will the above assumptions break?.

1. In users collection we are storing the roles as follows user: { roles: { SUPER_USER: 1, MEMBER: 1 } }

2. So Let's suppose we have implemented our changes and now a document in the user's collections will be as follows user: { roles: { SUPER_USER: 1, MEMBER: 1, DEVELOPER: 1, DESIGNER: 1, } }

3. So as a SUPER_USER I change the name of the DEVELOPER TO SOFTWARE_DEVELOPER in the roles collection in that case I need to change the existing occurrence of the DEVELOPER in the Users collection.

4. Instead of the latter approach, we can store some unique value (uniquely generated code maybe) that we can use to perform a lookup in roles collection.

Regarding the Naming of professional_tags to tags.

Yes I do agree that tags can be used instead of professional_tags but at the same time I believe that the name should be self-explanatory

Skeleton of Roles collection

Yet To Be Decided

[ganshul34]

@pallabez Here is the high-level architectural diagram of the relationship between users and roles collection.

RDS__ROLES_USER LINK

[ganshul34]

@pallabez as discussed I am not creating a new collection but modifying role constants and relevant files to keep the latency low and maybe in the future, we can go with the above approach.

[vinayak-trivedi]

Hey @ganshul34 can we use a collection called tags which contains all types of tags, @Mir-SA is working on it we can store all these tags in the tags collection and give it a type roles and then in the roles fields in the user object we can use the ID of these tags

check this issue