Added a field identifier to the User Collection

[shankeleven]

What kind of change does this PR introduce?

feature

Issue Number: #1554

Did you add tests for your changes?

yes

Summary

added a new field named identifier to the User, which is

• unique
• numeric
• immutable
• incremental & sequential
• automatically generated for every user when registering
• the count for identifier persists between server restarts

Does this PR introduce a breaking change?

no

[github-actions[bot]]

Our Pull Request Approval Process

We have these basic policies to make the approval process smoother for our volunteer team.

Testing Your Code

Please make sure your code passes all tests. Our test code coverage system will fail if these conditions occur:

1. The overall code coverage drops below the target threshold of the repository
2. Any file in the pull request has code coverage levels below the repository threshold
3. Merge conflicts

The process helps maintain the overall reliability of the code base and is a prerequisite for getting your PR approved. Assigned reviewers regularly review the PR queue and tend to focus on PRs that are passing.

Reviewers

Do not assign reviewers. Our Queue Monitors will review your PR and assign them. When your PR has been assigned reviewers contact them to get your code reviewed and approved via:

1. comments in this PR or
2. our slack channel

Reviewing Your Code

Your reviewer(s) will have the following roles:

1. arbitrators of future discussions with other contributors about the validity of your changes
2. point of contact for evaluating the validity of your work
3. person who verifies matching issues by others that should be closed.
4. person who gives general guidance in fixing your tests

CONTRIBUTING.md

Read our CONTRIBUTING.md file. Most importantly:

1. PRs with issues not assigned to you will be closed by the reviewer
2. Fix the first comment in the PR so that each issue listed automatically closes

Other

1. :dart: Please be considerate of our volunteers' time. Contacting the person who assigned the reviewers is not advised unless they ask for your input. Do not @ the person who did the assignment otherwise.
2. Read the CONTRIBUTING.md file make

[shankeleven]

@Cioppolo14 ma'am please review this pull request

[Cioppolo14]

@shankeleven Can you fix the failing linting related tests?

[shankeleven]

@shankeleven Can you fix the failing linting related tests?

sure ma'am i am just curious about how come does his pull request have no reviewers assigned automatically not even @palisadoes he is always the reviewer as he owns the repo

[shankeleven]

@palisadoes @xoldyckk @Cioppolo14 please assign some reviewers to this PR

[Cioppolo14]

@shankeleven Sorry I missed your response. Palisadoes is not the main reviewer of the pull requests. We have a set of volunteer reviewers, but we try to do a check first to make sure we are as efficient with everyone's time as possible. Feel free to @ me, or even find me on slack if something gets lost. Please fix the failing & skipped tests, then we will assign reviewers.

[palisadoes]

NOTE Read very carefully

1. We just merged this PR which upgraded the prettier package.
   1. https://github.com/PalisadoesFoundation/talawa-api/pull/1840
2. It reformatted over 400 files. This will put your PR at risk of extensive merge conflicts.
3. I suggest that before you merge your code to the latest upstream, or manually fix these merge conflicts that you:
   1. upgrade your prettier in your local branch to the same version
   2. run prettier

This will help to reduce the number of future merge conflicts for your PR.

[shankeleven]

@xoldyckk please let me know if there are any more changes required

[SiddheshKukade]

@shankeleven please take a pull from origin develop

[SiddheshKukade]

@shankeleven please fix the linting errors.

[shankeleven]

@shankeleven please take a pull from origin develop

done sir

@shankeleven please fix the linting errors.

these linting errors are from files that i have not edited and are not relevant to this issue so i thought it wouldn't be good to change anything in the files not related to the issue i could do it if permitted though.

[palisadoes]

We reverted the PR causing the linting problem. Update with your upstream

[palisadoes]

If merging with the latest upstream doesn't work, then please lint the offending file.

[shankeleven]

If merging with the latest upstream doesn't work, then please lint the offending file.

sure sir

[palisadoes]

Please fix the linting errors so we can merge this

[palisadoes]

If you click on the link of the failed tests, you'll see this. You'll need to edit these files to fix the linting. Sometimes they are files that you didn't edit directly, but ones that were affected by merge conflicts. We cannot merge code that hasn't been fully tested

[xoldd]

seems mongodb doesn't support auto-incrementing ids at the database level, so you're using this workaround to implement the same logic in talawa-api

@shankeleven why can't you simply fetch the user with greatest identifier and assign the user being created an identifier value of fetched user identfier + 1? why a seperate schema for identifier is needed here, care to explain your rationale behind this?

[shankeleven]

seems mongodb doesn't support auto-incrementing ids at the database level, so you're using this workaround to implement the same logic in talawa-api

@shankeleven why can't you simply fetch the user with greatest identifier and assign the user being created an identifier value of fetched user identfier + 1? why a seperate schema for identifier is needed here, care to explain your rationale behind this?

Sure sir, there are actually a few reasons behind chosing this specific approach, some fundamental and some for long term.

• when multiple requests are being processed simultaneously, fetching the user with the greatest identifier and then incrementing it can lead to race conditions. In a high-concurrency environment, multiple requests might fetch the same greatest identifier and attempt to use it, leading to conflicts and as a result the identifier may end up not being unique which would cause errors.

• Fetching the user with the greatest identifier every time a new user is created can be less efficient, especially as the database grows and the number of users increases.

• As the platform scales and we distribute our database across multiple servers or shards, managing a separate schema for the identifier count provides better scalability options. It ensures that the identifier generation process remains consistent and reliable across distributed environments.

[xoldd]

@shankeleven there are two seperate mutation operations to the database, since it's not a transaction atomicity isn't guaranteed, does mongodb support transactions? is it doable?

[palisadoes]

@shankeleven Please address the questions from @xoldyckk

[palisadoes]

@shankeleven

1. We'd like to merge this PR.
2. Please go through the review questions, update the PR as requested and mark them as resolved when completed

[palisadoes]

Please also fix the failing tests (linting)

[shankeleven]

@shankeleven there are two seperate mutation operations to the database, since it's not a transaction atomicity isn't guaranteed, does mongodb support transactions? is it doable?

sorry for overlooking the question yes mongodb does support transactions but my main rationale behind not implementing the transactions was to reduce the resources overload that comes along the transactions as even in the worst case if a registration fails for the user and the identifier still increases, we would still be fulfilling all the essential criteria for the field identifier i.e. incremental , numeric , unique and besides, we would anyways have the count of total registered users available all the time so i thought there was no need to implement a transaction here.

[DMills27]

@shankeleven Can you fix the failing tests?

[palisadoes]

This is an update on the PR merging freeze:

1. In the next few hours we will be merging the develop-userTypeFix branch into the develop branch.
2. The develop-userTypeFix branch was created to fix a long standing design flaw where Admins were Admins of all organizations, not specific ones.
3. The userType field has been removed from the User collection and it has been replaced by an appUserProfileId field.
   1. This field is null if the user isn’t registered to use the apps. This will help people to add users manually during the event checkin process, or if an Admin wants to manually add someone in the Admin dashboard.
   2. When not null the AppUserProfileID will reference a AppUserProfile collection with App related information such as the organizations for which a user may be an Admin.
   3. The updated schema can be found here https://github.com/PalisadoesFoundation/talawa-api/blob/develop-userTypeFix/schema.graphql
   4. This is the parent issue that we have been using to track progress:
      1. https://github.com/PalisadoesFoundation/talawa-api/issues/1965
4. This merge will cause some conflicts in your PR.

We decided to do this at the beginning of the weekend to give us all time to adjust PR code and create bug fixes that may arise.

Update your code at or after midnight GMT on the morning of March 23, 2024. (5:30am IST).

If your PRs have already been approved, request a re-review after fixing the conflicts and refactoring to the new AppUserProfileID methodology.

[palisadoes]

The PR merging freeze is lifted.

1. We are working on bug fixes that may arise. These should be few and are being tracked here:
   1. https://github.com/orgs/PalisadoesFoundation/projects/24
2. Please update your PRs and local repos. Fix any new merge conflicts that may have occurred.

Background:

1. The develop-userTypeFix branch was created to fix a long standing design flaw where Admins were Admins of all organizations, not specific ones.
2. The userType field has been removed from the User collection and it has been replaced by an appUserProfileId field.
   1. This field is null if the user isn’t registered to use the apps. This will help people to add users manually during the event checkin process, or if an Admin wants to manually add someone in the Admin dashboard.
   2. When not null the AppUserProfileID will reference a AppUserProfile collection with App related information such as the organizations for which a user may be an Admin.
   3. The updated schema can be found here https://github.com/PalisadoesFoundation/talawa-api/blob/develop-userTypeFix/schema.graphql
   4. This is the parent issue that we have been using to track progress:
      1. https://github.com/PalisadoesFoundation/talawa-api/issues/1965
3. If your PRs have already been approved, request a re-review after fixing the conflicts and refactoring to the new AppUserProfileID methodology.

[Cioppolo14]

@shankeleven Please fix the conflicting files and failed tests.

[palisadoes]

Closing as abandoned

[shankeleven]

quite saddening to see it closed as it took a decent amount of thought for proper implementation but fair enough.

[palisadoes]

We were going through the PRs, evaluating those that were probably abandoned. I'll reopen it. Your work wasn't in vain. Some of the PRs like this one, had been open for months.