NoMongo: Organizations created by the `API_ADMINISTRATOR_USER_EMAIL_ADDRESS` are not visible in the UI/UX

[palisadoes]

Describe the bug

1. The creation of an organization by the API_ADMINISTRATOR_USER_EMAIL_ADDRESS using the CLI graphql or interactive GraphQL doesn't make the API_ADMINISTRATOR_USER_EMAIL_ADDRESS have access to the organization in the organization dashboard.
2. The API_ADMINISTRATOR_USER_EMAIL_ADDRESS user must have access by definition.
   1. https://docs.talawa.io/docs/introduction/core-concepts
3. The process describing the use of GraphQL or curl to create organizations appears to create organizations - https://docs-api.talawa.io/docs/developer-resources/testing#using-graphiql

To Reproduce Steps to reproduce the behavior:

1. Follow the instructions
2. The organization appears to be created
3. The organization does not appear in the web UI dashboard

Expected behavior

• See above

Actual behavior

Screenshots

• N/A

Additional details

• N/A

Potential internship candidates

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

• https://github.com/PalisadoesFoundation/talawa/issues/359

[rahulch07]

please assign

[prayanshchh]

assign

[github-actions[bot]]

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.

[Cioppolo14]

Unassigning due to inactivity and/or no submitted PR. Others need to get a chance. Please let us know whether you want to be reassigned before someone else requests assignment or select another issue.

[rahulch07]

@Cioppolo14 please reassign was working on other issue with priority. Also have started to work on this would get this done soon

[rahulch07]

@palisadoes PTAL

after carefully observing and thinking thoroughly I came up with 2 solution for this problem:

1. Short-Term Solution (Manually Adding [email protected])

Current Workflow

1. The code fetches the user's ID from the database and checks if role === 'administrator'.
2. The organization is created in the database.
3. A separate query is required to add the current user as a member of the organization.

Proposed Fix

Modify the createOrganization mutation to automatically insert [email protected] as a member:

const [createdOrganizationMembership] = await ctx.drizzleClient
  .insert(organizationMembershipsTable)
  .values({
    creatorId: xyz,
    memberId: xyz,
    organizationId: parsedArgs.input.organizationId,
    role: "administrator",
  })
  .returning();

Here, xyz is the user ID of [email protected]. Also for other operation where api_administrator should have access similar approach should be followed

2) RBCA (Role Based access control)

1. Create a new role api_administrator. In core concepts we are supposed to have an API_ADMINISTRATOR but it is not yet implemented.
2. In this ways not only this problem will be solved but every other operation where api_administrator should by defination have permission can be implemented.
3. This method is more scalable and maintainable. Also it will solve the security issue as we are planning to implement here. This will be a good way to start this https://docs.google.com/document/d/16fJEZQHzji_RuarBn-33UvFYUh78ERZPKRFyTnvxyxc/edit?pli=1&tab=t.0#heading=h.ba55e9cy9rj4

please suggest an approach

[palisadoes]

Thanks

1. Update the mutation.
2. Add the RBAC option to the document as a phase 2 implementation. We can figure out the timing later.

[xoldd]

Administrator users don't need to be a member of an organization to perform read/write operations on it. Only organization members need to do that. API_ADMINISTRATOR_EMAIL_ADDRESS is just an initial administrator user that is made sure to exist on api startup.

You can add Query.organizations to get the list of all organizations in the application which should only be accessible by users with administrator role. Right now only Query.organization exists. For organization members with administrator role within that organization, User.organizationsMemberOf with an administrator role filter can be added.

[rahulch07]

Administrator users don't need to be a member of an organization to perform read/write operations on it. Only organization members need to do that. API_ADMINISTRATOR_EMAIL_ADDRESS is just an initial administrator user that is made sure to exist on api startup.

You can add Query.organizations to get the list of all organizations in the application which should only be accessible by users with administrator role. Right now only Query.organization exists. For organization members with administrator role within that organization, User.organizationsMemberOf with an administrator role filter can be added.

@xoldd @palisadoes

Got it. So currently, there is no distinction between an administrator for a specific organization and an API administrator—there is just one universal role, "administrator", which has access to all functionalities. Is that correct?

1)Does this mean that any user with the "administrator" role can modify any organization?(events, posts, venue, agenda, etc) 2)Also, on the "My Organization" screen, should all organizations be displayed even if the user is not a member of them?

[xoldd]

@rahulch07 There is no exclusive API administrator. Idk where this term has surfaced from. I guess this environment variable? The API_ prefix in those environment variables is to differentiate the environment variables required by api service from the environment variables required by other services in the docker compose files because I didn't want to use seperate .env files for each service as they can overlap sometimes.

1)Does this mean that any user with the "administrator" role can modify any organization?(events, posts, venue, agenda, etc)

Mostly yes. But it needs to be determined what they can or cannot update after introspecting on the business logic of talawa. For example, they shouldn't be allowed to change the contents of a comment left by another user. They should only be allowed to delete it if they wish to do so. Only the creator of a comment should be allowed to change its contents. Some of this behavior is present in some of the graphql resolvers of develop-postgres branch. More can be added where it is seen fit.

2)Also, on the "My Organization" screen, should all organizations be displayed even if the user is not a member of them?

If the client has an administrator user role then they should be able to see all organizations in the application. If the client has a regular user role then they should only see the organizations in which they have an administrator member role. So, My Organization screen doesn't really sound correct. Choose something that fits better I guess.

[rahulch07]

@xoldd API ADMINISTRATOR term is used in the docs https://docs.talawa.io/docs/getting-started/core-concepts#administrators. There is only one Api administrator across all organizations in a particular community.

[xoldd]

@rahulch07 those docs are incorrect

[palisadoes]

The document has been updated

[rahulch07]

@palisadoes when #3244 will make a organizations query. I will update the /orglist component to fetch all the organizations. So this issue will be solved. Should this issue be closed till then? As I wont be able to work on other issues as this is assigned to me.

Also

2. Add the RBAC option to the document as a phase 2 implementation. We can figure out the timing later.

I would be happy to work on RBAC whenever we implement it. I think we should start it early as it would take time to implement it, so it can be done in parallel to other issues.

[igennova]

i have created organizations query and submitted a pr waiting for the review

[rahulch07]

@palisadoes @xoldd wanted to clear some doubt.

suppose a user with role='regular' in users table in database. Now he is made administrator of an organization org1 using mutation updateOrganizationMembership (role='administrator' in organization_memberships table).

1. Should he be able to login as administrator from admin tab. If yes the problem is he will also be able to see organization of whom he is not admin

[palisadoes]

Regular users, who are org admins must login and only get access to the admin screens of the organization. They must not have access to the general user information. They must have access to the member information of the organization.