Add basic multiple admin users support

[M1CK431]

⚠️⚠️⚠️ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma

Tick the checkbox if you understand [x]:

• I have read and understand the pull request rules.

Description

Add a very basic multiple admin users support.

ℹ️ This PR is already reviewed by @CommanderStorm and @chakflying (at least partially for the later). I really would like to thanks them a lot for help and advises while on boarding a new contributor. It was a pleasure to work with them 🤗

Fixes #128 (in a very basic/partial way)

Per commit review hugely recommended due to this PR size. I really take care about git commits history to easy the review for @louislam

Type of change

• User interface (UI)
• New feature (non-breaking change which adds functionality)
• This change requires a documentation update => I don't know 🤷🏼‍♂️

Checklist

• My code follows the style guidelines of this project
• I ran ESLint and other linters for modified files
• I have performed a self-review of my own code and tested it
• I have commented my code, particularly in hard-to-understand areas
  (including JSDoc for methods)
• My changes generate no new warnings
• My code needed automated testing. I have added them (this is optional task)

Screenshots (if any)

Users list:

Confirm modal on disabling user:

Add an admin account:

Edit an admin account:

[CommanderStorm]

In the Proto-PR we had a discussion about the value and need for tests in this PR.
I believe that security-related PRs should always come with tests to catch future regressions.

Normally, I would offer to provide a PR next week, but next week will be hell work-wise already
⇒ If somebody from #128 wants to provide an audit via implementing some of the above tests, this would be really appreciated

TLDR:

Given that this is a security-relevant PR, I think these cases should be covered (all as cypress-e2e testcases which are verifed by looking at the database + UI):

• adding a user adds it => user can log in
• disabling user marks the user as disabled => user cannot log in
• enabling user marks the user as disabled => user can log in
• removing a user removes the user => user cannot log in

[M1CK431]

Just a couple of things, mainly about JSDoc comments. A PR was recently merged into the version 2 branch (#3529) which added JSDoc rules to eslint.

Well, I'm opening a PR on v1.x series... I have do my best but please keep in mind that it's a bit hard to handle such review without the related eslint rules configured... In addition, it's the first time I use JSDoc (very nice).

The key ones from that were @params and @returns require descriptions in all cases (except @returns {void} and @returns {Promise<void>}, all JSDoc comments for methods and functions require an @returns, object is preferred over Object and optional arguments should not document their default values if the default values are given in es6 syntax. I haven't added a review comment for each as to avoid cluttered everything. https://github.com/gajus/eslint-plugin-jsdoc#readme

I just push an update on this PR where I try to exhaustively take care about that. As already explained, since there is no such eslint rule in v1.x series, please tell me if there is still something to change 🙏🏼

[Rovel]

I can help with some cypress tests, if still needed.

I saw the project have some Github codespaces config files, and saw some setups to test cypress with them I can open a PR on that too
cypress-io/cypress-documentation#2956
https://devopstar.com/2022/01/03/cypress-testing-in-devcontainers-and-github-codespaces/

I also recommend to setup cypress cloud with an OSS plan to help testing and debugging cypress tests: (easy setup) https://docs.cypress.io/guides/cloud/account-management/billing-and-usage#Open-Source-Plan

[Rovel]

@CommanderStorm @Rovel Is there still one of you hotter than 🔥 to write some test as requested to merge this PR? 🥺

M1CK431#2

I tried to find a branch to PR this on the main remote but couldn't find it

[M1CK431]

@Rovel Just merged it so your commits are here now. THANKS A LOT!! 😘 ❤️
@CommanderStorm So now we have unit test. What is the next step?
I notice some conflits, should I resolve them now? Is that PR merged once conflits will be resolved?

[Rovel]

@M1CK431 I added a secondary PR with cy tests on the edit user form in M1CK431#3
There is one point in this test, the secondary user created can incativate de original/default user and kind of lock him out, not sure if is in the scope of this PR but avoiding the root user to be inactivated by others would be advisable, not that db access cannot solve but I needed to mention.

[BenjaminEHowe]

avoiding the root user to be inactivated by others would be advisable

IMO that's out of scope for this PR -- all users are admins, and admins should be able to create and delete accounts. That said, I suspect in future the idea of user roles might be added, and non-admins probably shouldn't be able to add or remove users.

[M1CK431]

@Rovel Thanks a lot for your work, I just merged it.

To answer your question, once this PR will be merged, the concept of "root" user doesn't exist anymore. There is just (admin) users, period. As @BenjaminEHowe mention, we could imagine adding a rights management system (ACL, RBAC, etc...) in the futur, but this is totally out of scope of this PR.

As you know, it's already a big change and so I would like to keep things as simple as possible. Anyway, thanks for your question, it's a pleasure to work with invested people 😍

[M1CK431]

@CommanderStorm @louislam So now we have many unit tests! What is the next step?
I notice some conflits, should I resolve them now? Is that PR merged once conflits will be resolved?

[CommanderStorm]

@M1CK431
I am only doing issues and a bit of project management (in the loose sense). Occasionally, I do preliminary reviews on PRs, but I am not a maintainer myself.
Louis maintains this project and Nelson helps him with that.
Pinging will not get this PR merged faster, more likely slower.

Currently, our pipeline is quite blocked with getting the v2.0-milestone and v2.1-milestone out of the door.

[M1CK431]

Thanks for your reply @CommanderStorm.

Pinging will not get this PR merged faster, more likely slower.

I think I'm not too demanding: this PR is open since august...

Louis maintains this project and Nelson helps him with that.

Thanks, so perhaps @chakflying could reply to my question?

[chakflying]

• there is still non-trivial amount of work to be done to get 2.0 released (mostly testing)
• Even if this gets adopted, once there is support for multiple users, we then need to check for concurrency issues across the whole application. Things like making sure changes made in 1 client should propagate to all clients, what happens when a client submits outdated/invalid data. Realistically, it would probably take a full release cycle just working on this. We can't just merge it and release it half-way.
• There is no team here, just a person with free time. There is no schedule, things get done when there is time and interest. There will be merge conflicts, and things can get broken along the way. You may choose to fix them, or you may not. But it's a burden that someone must take, whether it be the maintainer or a PR author, in a project with many contributors and no coordination.

[M1CK431]

there is still non-trivial amount of work to be done to get 2.0 released (mostly testing)

This PR is proposed on v1.x series.

• Even if this gets adopted, once there is support for multiple users, we then need to check for concurrency issues across the whole application. Things like making sure changes made in 1 client should propagate to all clients, what happens when a client submits outdated/invalid data. Realistically, it would probably take a full release cycle just working on this. We can't just merge it and release it half-way.

Sorry, I can't agree with that. The current situation in real world use case is that the only possible account is shared between multiple users. With the changes I made, the situation is exactly the same regarding changes propagations, outdated data, etc... except that each users is connected with it's own account. Consequently there is absolutely no extra work needed.

• There is no team here, just a person with free time. There is no schedule, things get done when there is time and interest. There will be merge conflicts, and things can get broken along the way. You may choose to fix them, or you may not. But it's a burden that someone must take, whether it be the maintainer or a PR author, in a project with many contributors and no coordination.

Yes, I'm myself a person with (very few) free time. Because of that, I don't want to waste my time to rebase/resolve conflits again and again. That's why I ask first a review by a maintainer which as the power to say "ok, this code is good, just rebase/resolve conflits and I will merge it". Are you this one @chakflying ?

[chakflying]

• There will be no new features on v1 as per the 1.23.0 release notes.
• Yes, conceptually there is no difference. But currently, if 2 people need to work on the application, they will have to share an account, and IMO there would be an implicit understanding that things may not work well if you make changes at the same time. But if multiple accounts are supported, there would be no such assumption.
• Then I suggest you wait until this gets added to a milestone before paying any more attention to it, because I'm not the one to make that decision :)

[M1CK431]

There will be no new features on v1 as per the 1.23.0 release notes.

Ok things are clear now: this PR will never be merged.

Yes, conceptually there is no difference. But currently, if 2 people need to work on the application, they will have to share an account, and IMO there would be an implicit understanding that things may not work well if you make changes at the same time. But if multiple accounts are supported, there would be no such assumption.

Currently, when 2 people works at the same time on the same monitor (which is a very corner case in real world), things works perfectly: the last save overwrite the DB content. Expected behavior, right? My changes doesn't impact that in any way. For any other changes, well there is WS for that and I have tested it myself when I was working on that feature: no problem. In addition, I'm using my patched version in production since months, without any issue.

Then I suggest you wait until this gets added to a milestone before paying any more attention to it, because I'm not the one to make that decision :)

Considering the fact that this PR will never be merged, I guess there is no more attention to pay at all... 😭
The only solution I have now is to fork the projet, a "solution" I hate because, IMHO, it's exaclty that kind of things which penalizes many open source products: fragmentation.

Anyway, thanks for the time you spent replying me 😘

[M1CK431]

Hi @louislam @CommanderStorm @chakflying 👋🏼
FYI I just rebase that PR on master (so v2.0.0) for my own needs.

Also I notice (with joy!) that this feature is now part of milestone 2.1.0 and that milestone 2.0.0 is almost reaching the end (96%). Now waiting a little sign from your side to finalize and merge that work 😘

EDIT: I update it again mainly to please new linter rules. However there are still some "strange" errors (for ex: complaint about JSDoc optional params default values 🤷🏼‍♂️, complaint about Cypress related keywords...). I'm not sure about that so I keep them as is for now. Would be happy to have explanation through.

[Zaid-maker]

@M1CK431 cypress is dropped in 2.0.0 that's why the check-liner run fails

[M1CK431]

@M1CK431 cypress is dropped in 2.0.0 that's why the check-liner run fails

Ok thanks. So I should remove all test related files from this PR, right @Zaid-maker ?

[Zaid-maker]

So I should remove all test related files from this PR, right @Zaid-maker ?

Convert them to playwright testing instead if it's OK for you

[M1CK431]

So I should remove all test related files from this PR, right @Zaid-maker ?

Convert them to playwright testing instead if it's OK for you

I don't know how to do this. The cypress tests existing in this PR was done by @Rovel.
Still, I will remove the useless cypress tests files and hope someone with the necessary knowledge will add playwright ones.

[M1CK431]

@Zaid-maker I just remove the cypress tests files. There are still a few linter errors related to:

Optional param names are not permitted on @param jsdoc/no-defaults

I don't understand why this linter rule even exist since an optional parameter often have a default value. Developers probably want to knows about that default value to determine if a different value is needed depending of the use case 🤔

[Zaid-maker]

If its exist maybe it's for good cause, still wait for Louis to review the PR, or maybe I could look into the issue when I get free

[Ionys320]

If needed, I may try to add permissions system after, when this PR will be merged. It can be a game-changer for large structures (in my use case).

[vishalsabhaya]

@M1CK431 @chakflying @CommanderStorm

in this pr multiple user support changes are done.

could we add below changes. it would helpful to everyone

1. we can add non login users like mail or mobile number(encripted format save)
   -> it will improve notification feature who are notifying to mail/ mobile number

2. tenant support
   -> by using tenant it will help to isolate users for multiple system or multiple team
   by adding company or tenant table. default id will be create for each first user.

   for example: I want to monitor my website of a different project but cannot share credentials because of all are monitor in same instance. for saving cost I want to use single instance only.

[Ionys320]

@vishalsabhaya The tenant aspect may be handled by the permissions system. A "brainstorm" will be made in a dedicated issue when this PR will be finished.

Regarding saving non-login users, I'm not sure of what you're talking about (I'm not mentionned, so maybe others will understand), but I don't know what is the link between this and the PR (like this PR is to add several users, but you mention storing non-login users).

[M1CK431]

@M1CK431 @chakflying @CommanderStorm

in this pr multiple user support changes are done.

could we add below changes. it would helpful to everyone

1. we can add non login users like mail or mobile number(encripted format save)
   -> it will improve notification feature who are notifying to mail/ mobile number
2. tenant support
   -> by using tenant it will help to isolate users for multiple system or multiple team
   by adding company or tenant table. default id will be create for each first user.
   for example: I want to monitor my website of a different project but cannot share credentials because of all are monitor in same instance. for saving cost I want to use single instance only.

Hi @vishalsabhaya ,

Please refer to this comment to understand why nothing will be added in this PR.

[vishalsabhaya]

@Ionys320 @M1CK431

Thank you for sharing information regarding permission.

Consider there is several big departments. each department & management is isolated to each other. infrastructure is common but management person is different.

so by considering this. we can include tenant. of course permission set also required. why should we not include both?

we already change all query. it will be simple change by adding tenant_id & data migration script for tenant.

I can contribute if you all agree.

Regarding saving non-login users. i am using uptimerobot. there you can create contacts like email, mobile no. if login is allow then it will consider mail for login. it will very useful for notify existing contact.

[Ionys320]

@vishalsabhaya I saved your comment for when I'll work on the permissions system. I think it's better not having several PRs on the same topic to avoid merge conflicts as much as possible, but the tenant system is interesting and could indeed be used to have a simplier team management. As I said previously, permissions will be a topic we'll need to discuss before working on it, several things must be set before. Therefore, it's too early to clearly define specs without having a global vision, but as I said previously, an issue by me will be created after this PR approbation!

[vishalsabhaya]

@Ionys320
ok understood. thank you for sharing.