Allow basic User management without permissions

[Nicklas2751]

I host some services together with some friends, I'd like to let them add some Monitors but not to change the notification settings or change/delete monitors of others. To achieve this, it would be nice to have a small user management where I can create roles, set privileges for roles, create users and assign users to roles.

Additional: When I look at other feature requests like the one with the API, this could be a good base to create technical accounts which then are able to access the API with a generated API token or something like that.

[slickware]

Bumping this with my vote as well. I'd love to be able to allow friends/coworkers access to a subset of monitors on my instance, but at the moment I cannot without sharing the single solitary user account/password... which is just terrible security in 2024. Any method would be fantastic, even local accounts at this point - it doesn't need to be enterprise-grade, but some user permission ability would be amazing.

[CommanderStorm]

I am going to lock the conversation on this thread, as the constant bumping (thus pinging many people without any content) is not helping to make this issue more managable/readable. I don't think more needs to be said about this issue. @slickware (sorry to single you out like this) The correct way to "bump" something is to add a 👍🏻 on issues and to only comment if value can be added. Posting +1 / requests for updates things on issues, makes issue-management a lot harder because they also require maintainer time.

The status of https://github.com/louislam/uptime-kuma/issues/128#issuecomment-1676504440 has not changed, the PR #3571 has been slated for review. I encourage you/everyone to do a review and note issues introduced by said PR via the command used to test PRs in the Pull request.

[chakflying]

I think a comment with a good description of use case with "why I really want this" is not meaningless. Historically we have not done any user survey, we don't have a discord etc. to capture user feedback and experiences. User comments here have been the sole metric of user attention and their needs. Upvotes are helpful, but they do not provide context or timeliness.

Realistically, #3571 is still months away from even being considered. Can't speak for others but for me, issues do get "forgotten" as real life or other ideas get in the way. A gentle reminder doesn't make things go faster, but it also doesn't hurt.

Locking a thread is a big hammer, and I don't think it should be struck lightly. Maybe you don't like clicking on a notification to see no actionable content, but in general, I think tolerating a reasonable amount of "noise" (that is not pure spam) is a sign of a healthy community, and is valuable given how the project is run currently.

[CommanderStorm]

Honestly, every time I get such a notification, I somewhat feel the need to respond to it (my "chosen role" being somewhat into the direction of "project/community management"). Maybe just hiding comments as spam (instead of responding and thus making the important content go further up) is a practical solution?

Perhaps my current saved response also needs work in terms of openness/friendliness

> Please refrain from posting `+1` / requests for updates things on issues, as this makes issue-management harder. Issues are for discussing **what needs to be done how by whom**. [We use 👍🏻 on issues to prioritise work](https://github.com/louislam/uptime-kuma/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc), as always: [Pull Requests](https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md) welcome.

[ccoenen]

I would be totally fine with locking this issue.

I don't expect anyone to contribute meaningful insights to this. I think everyone involved is aware. The constant "oh, but I have an important need for this, surely this tips the scale" is really useless for everyone involved.

[bb]

I was happy to see this locked. Thanks @CommanderStorm. Here's a more complete list of good reasons: https://github.com/bradfitz/issue-tracker-behaviors

[M1CK431]

However contributors might want to post comments to provide progress update, right?

[douglasparker]

Yep, I'm also in favor of locking this issue.

I subscribe to notifications for issues that I am interested in that way I can follow development or discussion around development, but most of the time all I get is my email flooded with noise.

We all know this is a highly requested feature. I want it too. But all the extra noise just makes me want to unsubscribe.

You have to realize that a lot of us follow a LOT of projects and a lot of issues. When all of replies are bumps and +1's it gets annoying really quick.

[WoodyWoodsta]

Personal rule of thumb:

• issue has little to no engagement: add your context and any helpful info, by any means
• issue has >10 reactions or >10 comments: spare everyone the unhelpful notification

[somethingstarted]

i'd be fine with just multiple accounts with the ability to set permissions ranging from read only to full admin to disabled without deleting.