More modular Permission system

[marsh patrol]

As someone who uses txAdmin primarily for its monitor and auto-restart functions remotely, I noticed that even when creating an account with only restart permissions, the user can still see too much, in my opinion. For example, they still have access to options like the whitelist and dashboard. I would really love to have the ability to limit what each user can see — ideally, restricting their access to only a single specific permission or function.

[late carbon]

I mean, at some point, if the user cant even see the dashboard, stuff will just look weird and broken

at thet point its better to just disable the web ui for this user

or not even add them to the user list

[marsh patrol]

okay the dashboard thing is something i can understand some what, but the menu options in the picture https://i.imgur.com/HG3eqJM.png and the functions behind it does not make sense to me to still show it or be able to do something there like in the whitelist menu

[late carbon]

what in there is sensitive enough to justify hiding it from your admins?

[marsh patrol]

I just want to provide certain QA team members with the ability to restart the server, but strictly limit their access otherwise. Restricting permissions is common practice in our environment to prevent people from accidentally (or intentionally) changing configurations or accessing sensitive data.

One of the main reasons for limiting access is to avoid them seeing detailed activity logs, such as when other users were last active. We've seen that when people notice who was online and when, it can easily lead to unnecessary discussions, misunderstandings, or even conflicts — for example, questioning why someone was or wasn’t active at a certain time, or speculating about other people's responsibilities and work habits. These discussions quickly become disruptive and can harm team morale and focus.

This has actually been a recurring issue for us. Personally, I wouldn’t give them access at all, but unfortunately, there currently isn’t a safe, dedicated way to let them only restart the server in FiveM.

I’m waiting for the developer API of txAdmin, which might allow us to set up more granular permissions and create a safer, more controlled workflow. However, this API could still take several months to be released, so for now, we don't have a proper solution to delegate server restarts securely.

Another example is what happens on the dashboard. We’ve experienced cases where people took screenshots of system timings and internal metrics without fully understanding what they meant. They then spread these around, claiming the systems were inefficient or misconfigured, which sparked rumors and endless debates. Even after explanations are given, these discussions tend to persist because people focus on things outside their actual responsibilities.

[late carbon]

seems like you just dont want to use txAdmin at all... so don't

it's 1000x less effort you mock login+restart api calls yourself than for me to implement a granular API that even blocks dashboard access

bunch of ppl want to use txadmin, so I'll prioritize building stuff for them

[marsh patrol]

Don’t get me wrong — I don’t understand why you assume that we aren’t using txAdmin or don’t want to use it. As a server owner or developer, I think it’s great, no question about it. However, the point was to expand the user base in a way that doesn’t interfere with how we handle things internally.

Having things on a “need-to-know” basis isn’t unusual either. That’s why we requested the possibility of splitting permissions more granularly — so that more people in our project could actually use it.

The reason we want to use the API is precisely because, in the current state, we can’t expand the user base — especially for the reasons mentioned above.

I don’t know how I gave the impression that I don’t want to use txAdmin; quite the opposite — I definitely want to use it. But for that, the changes mentioned above would be very helpful.

I completely understand that this is no small request, and if it’s perceived negatively, feel free to decline it. In that case, we’ll just have to wait for the developer API and build our own solution on top of it.

(This isn’t meant as an attack, just to clarify before this gets interpreted as passive-aggressive.)

[vernal dock]

tl;dr, he's saying that your needs do not represent the vast majority of txAdmin servers. If you want to do all of that, hire a developer to do it for your server.

The API does not exist and probably will not for the foreseeable future.

[late carbon]

Sorry if my last message sounded a bit aggressive. I was more direct than usual because it was 7:40 am and I was heading to bed.
Don't worry, I completely understand you... All the time I find myself building something new just because I didn't want to deal with some inconvenience from the existing solutions.
I even understand the "need-to-know" part (in the industry, usually called principle of least privilege).

The issue is that there is a great asymmetry in the amount of effort this requires from my part vs from your workaround, and even bigger asymmetry in the time investment and the ROI I would see, considering the huge list of features on my TODO list.

It's even in my TODO list to rename "admins" to "users", to remove the implicit minimum trust required for its users

[feral widget]

staff*

[late carbon]

goons**

[feral widget]

Gooners*