Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API - Select organization on registration #1703

Closed
palisadoes opened this issue Jan 16, 2024 · 39 comments
Closed

API - Select organization on registration #1703

palisadoes opened this issue Jan 16, 2024 · 39 comments
Assignees
Labels
feature request test Testing application

Comments

@palisadoes
Copy link
Contributor

palisadoes commented Jan 16, 2024

Is your feature request related to a problem? Please describe.

We are working on migrating the approval of requests to join organizations to a new Admin screen as outlined in this issue:

Prior to this the process was:

  1. New registrants joined the Community
  2. Super Admins would approve the request
  3. Approved registrants would login and select an organization

There were disadvantages to this approach:

  1. This gave too much responsibility to the Super Admin who may not necessarily know people requesting to join in the way an Admin would.
  2. The two step process where the organization was selected post approval, could have been reduced to a simpler single step.

Describe the solution you'd like

TALAWA API

  • This new requirement means that:
    1. New USERs and NON_USERs will need to select an organization when registering so that the request can be directed to the correct organization's Admin screens.
    2. The setup script needs to create a single organization with a generic name on installation to facilitate registration to choice of at least one organization
    3. There can never be less than one organization in the DB
    4. The registration mutation must include organization ID information that issue Add membership request feature for ADMIN  talawa-admin#1416 will be able to detect.
    5. The current GitHub action pull request workflow needs to be updated so that the default organization is created successfully. This is in addition to the already existing test data importation test.
    6. The default organization creation mode mutation needs set the registration approval required flag to True to err on the side of caution.

TALAWA MOBILE

  • This new requirement means that:
    1. The user registration screen(s) will need to prompt for the organization and use the updated Talawa API registration mutation.
    2. The screen(s) design must follow the guidelines of our Design System found here:

TALAWA ADMIN

  • This new requirement means that:
    1. The user registration screen(s) will need to prompt for the organization and use the updated Talawa API registration mutation.
    2. The screen(s) design must follow the guidelines of our Design System found here:

OTHER

  1. You will need to write tests for the updated code
  2. All other functionality must be maintained

Describe alternatives you've considered

  • N/A

Approach to be followed (optional)

  • See above

Additional context

  1. Related issues:
    1. API - Select organization on registration #1703
    2. Mobile - Select organization on registration talawa#2330
    3. Admin - Select organization on registration talawa-admin#1440
  2. User definitions in the DB schema
    image

Potential internship candidates
Please read this if you are planning to apply for a Palisadoes Foundation internship

@Manik2708
Copy link

Hey @palisadoes can you assign this issue to me?

@NayOoLwin5
Copy link

I would like to work on it.

@lakshz
Copy link
Contributor

lakshz commented Jan 16, 2024

I'd like work on this

@AVtheking
Copy link

i would like to work on this sir please assign me this issue

@Cioppolo14 Cioppolo14 removed the unapproved Unapproved for Pull Request label Jan 17, 2024
@Manik2708
Copy link

Hey, I am facing a problem, when an user is created an organization is asked from the user itslef
Screenshot from 2024-01-18 00-15-16
And when membership request is made, a check is made that too with the admin of organization not superadmin
Screenshot from 2024-01-18 00-17-23
So which registration is being talked about here? Can I get little more context?

@palisadoes
Copy link
Contributor Author

This is related to a brand new user registering via the API selecting the organization that they want to be a member of.

BTW organizationUserBelongsto was deprecated yesterday

@palisadoes
Copy link
Contributor Author

  1. As explained in the initial comment. Super Admins used to do the approvals, we now want this to be done by Admins.
  2. When a user is already in the system, they should be able to select organizations to join

Is there other clarification you require?

@Manik2708
Copy link

So most of the logic has been made by me, please see the steps: (Only an overview)

  1. As said in above comment organizationUserBelongsto is deprecated but not completely removed yet. That check will be removed completely in this issue.
  2. The mutation SignUp will take Organization as a parameter, if it is null, default organization will be added in that user schema.
  3. A membership request will be sent to the organization in this mutation.
  4. createMember mutation will get rid of superAdmin
  5. The isAdminAprooved will be made true in SignUp mutation.
  6. The default organization will always be present no matter how many more organizations are joined by user.

My Questions:

  1. The problem which I am facing is creating that default organization, should I add more commands to generate this default organization or just add this in the sample database?
  2. Should I try for getting rid of isAdminAprooved variable as it will always be true?

@palisadoes
Copy link
Contributor Author

  1. The default organization will need to be created automatically
    1. with setup if the DB is empty.
    2. as part of the sample database importation
  2. What does the isAdminApproved logic do?
  3. Yes cleanup organizationUserBelongsto

@Manik2708
Copy link

Clear! gonna check Talawa Admin for handling this logic. Will raise the PR as soon as possible! Thanks for your cooperation!

@palisadoes
Copy link
Contributor Author

You still haven't explained what the isAdminApproved logic does

@Manik2708
Copy link

You still haven't explained what the isAdminApproved logic does

The unauthorised error is being sent by Talawa Admin when isAdminAprooved is false. Now there are two cases:

  1. User tries to enter the Admin site without any Organization.
  2. User already know his Organization.
    For the first case, the registration mutation has to make this bool variable true, so that User can enter the Admin pannel and then select organization. In the second case a membership request has to be made, then only this variable will become true.
    Initially I thought to make this variable as true in the SignUp mutation but then the need wouldn't be followed as then all users would enter the Admin Panel to select organizations but this is very unsecured and unnecessary. So in the end my approach will be:
    If organization provided by user is null then isAdminAprooved has to become true in the registration mutation itself.
    Else a membership request will be sent to the organization with isAdminAprooved as false.

@palisadoes
Copy link
Contributor Author

  1. Why can't the user select the organization as part of a dropdown in the registration process so that they never have to get access to an Admin screen? The request would go straight to the Admin.
  2. If the the registration is approved, the user would go straight to their selected organization user portal screens

It seems like unnecessary logic.

@Manik2708
Copy link

  1. Why can't the user select the organization as part of a dropdown in the registration process so that they never have to get access to an Admin screen? The request would go straight to the Admin.
  2. If the the registration is approved, the user would go straight to their selected organization user portal screens

It seems like unnecessary logic.

So you are saying, Choosing Organization will be necessary. If user chooses the Default Organization, then membership request will be made to that default organization. Thanks for this clarification!

@palisadoes
Copy link
Contributor Author

Yes, we should be able to deprecate the field if we make selecting an organization on registration mandatory

@Manik2708
Copy link

I want to ask whether acceptAdmin mutation should be removed or not, because I think that it's only use is to accept the request of newly created member by superAdmin, Please let me know if I am wrong! Thanks

@palisadoes
Copy link
Contributor Author

  1. There is a userRegistrationRequired flag in the schema that is used to determine whether newly registered users need to be approved by an Admin to join the organization. It should really be named userRegistrationApprovalRequired
    image
  2. Is it related to that?

@Manik2708
Copy link

No, I am talking about this adminAprooved in Talawa Admin
IMG_20240121_125626
This is the mutation in Talawa API making it true
IMG_20240121_125739

@palisadoes
Copy link
Contributor Author

The logic is used throughout the Admin code but seems to be only set to false for testing purposes. Is that what you mean?

  1. Looking at the schema, I think it's a hack to make sure the user is always admin approved until the feature was truly fixed.
  2. It should really be part of an approval per organization.

This will need to be fixed as part of this issue. We need:

  1. New user registrations to be approved by the Admin (or automatically approved) depending on the userRegistrationRequired flag.
  2. Approvals on a per organization basis and reflected in the User schema.
    1. The Admin and Mobile repos will need to be adjusted accordingly.
  3. Users to only have the choice to easily switch between organizations for which they have been pre-approved, or else they will need to register with the new organization that they want to join.

@Manik2708
Copy link

So I have prepared two workflows, the only difference between those workflows is when user tries to SignUp with the organization which has userRegistrationRequired=false:

  1. A membership request will be made and no matter whether the above flag is true or false, Admins of the organization has to review the request.

WhatsApp Image 2024-01-21 at 17 54 06(2)
2) Or for only those users who have chosen that organization which have the above flag as false, request can be sent to superAdmins

WhatsApp Image 2024-01-21 at 17 54 06
If the requirement is to automatic approve the request sent to these organizations, then that can be also implemented but that will not be secured as any spam user could enter with that organization. I can think of more ways also, if you don't like the above workflows!

@palisadoes
Copy link
Contributor Author

The super admin is not required. If an admin says that they don't need to approve registrations / signups then the user should just log straight in.

Most cloud services are like this, there is an email verification step on signup, then you login. There is no human interaction. The registration approval required step is to involve a human, namely the Admin and in the Organization level screens.

The super admin role is primarily for the oversight of organizations. They should see organization specific alerts when they click through to the organizations from the Admin orglist screen.

@Manik2708
Copy link

Ok, so will work on this. Thanks!

@Manik2708
Copy link

@Manik2708

This had to be reverted. It was causing these issues

Please resubmit your PR

Ok, will fix it!

Copy link

This issue did not get any activity in the past 10 days and will be closed in 180 days if no update occurs. Please check if the develop branch has fixed it and report again or close the issue.

@github-actions github-actions bot added the no-issue-activity No issue activity label Feb 11, 2024
@Manik2708
Copy link

Working

@github-actions github-actions bot removed the no-issue-activity No issue activity label Feb 12, 2024
Copy link

This issue did not get any activity in the past 10 days and will be closed in 180 days if no update occurs. Please check if the develop branch has fixed it and report again or close the issue.

@github-actions github-actions bot added the no-issue-activity No issue activity label Feb 23, 2024
@Cioppolo14 Cioppolo14 removed the no-issue-activity No issue activity label Feb 23, 2024
@Olatade
Copy link

Olatade commented Feb 26, 2024

@Manik2708 are you still working on this ?

@Manik2708
Copy link

Yes, the PR is under review.

Copy link

github-actions bot commented Mar 8, 2024

This issue did not get any activity in the past 10 days and will be closed in 180 days if no update occurs. Please check if the develop branch has fixed it and report again or close the issue.

@github-actions github-actions bot added the no-issue-activity No issue activity label Mar 8, 2024
@Cioppolo14 Cioppolo14 removed the no-issue-activity No issue activity label Mar 8, 2024
Copy link

This issue did not get any activity in the past 10 days and will be closed in 180 days if no update occurs. Please check if the develop branch has fixed it and report again or close the issue.

@palisadoes
Copy link
Contributor Author

  • Unassigning.
  • 10 weeks without resolution.
  • This is open for someone else to attempt

@AVtheking
Copy link

I would like to work on it .

@palisadoes
Copy link
Contributor Author

@AVtheking You should also work on this issue as it's related. Please ask to be assigned.

@AVtheking
Copy link

Ok sir.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request test Testing application
Projects
Archived in project
Development

No branches or pull requests

8 participants