Permission problem with commands

[BerkieB]

I’m on the beta update channel on game build 2699, FXServer 5994.

I expected the restricted command I made which says I have I don’t have access to running it even though I have the group.admin principal which allows me the command ace (so I expect it to give me access to all commands) to restrict me from running it with key mapping as well, but when I use the mapped key, the command runs fine, then I try to execute it via the chat, it says I don’t have access.`

Well I actually expected to have access.

When I execute the following code, it prints false, which it should not because I have it set to allow the command ace to group.admin

print(IsPrincipalAceAllowed('group.admin', 'command'))

I set the principal using add_ace group.admin command allow as it does by default with a txAdmin recipe installation already and the only other permission I have set is my fivem id to group.admin as txAdmin does as well by default on a recipe.

Code I used to reproduce this issue

RegisterCommand('testingmapping', function()
    print('mapping')
end, true)

RegisterKeyMapping('testingmapping', 'Testing this', 'KEYBOARD', 'H')

All this code was run on the client

I tested it on the server and when running print(IsPrincipalAceAllowed('group.admin', 'command')) it does print true as it should.

[Linden]

Even though the restricted argument exists on the client, as well as IsPrincipalAceAllowed and IsAceAllowed, ACL isn’t synced to the client at all.

Native IsAceAllowed() won't work as expected

Client: 2373/canary b2545 FxServer: 2531 win32 b2545 Expected: IsAceAllowed return value equals to IsPlayerAceAllowed() on server side Now happens: If i use IsAceAllowed it returns false for object that equivalent server sided native returns true Category: native/client Reproduction steps: Player has group.admin principal Register ace permission in server config add_ace group.admin “BLAdmin.Global.HasPermissions” allow Check permission on server side -- source is player source …

@nta

This isn’t a ‘bug’, this is intentionally not implemented at this time (as synchronizing part of an ACL that applies to certain principals only is a somewhat failure-prone scenario, and this is a relatively rare request + server owners wouldn’t want their ‘full’ ACL to be ‘sent to every client’, so this kind of evaluation would need to account for a lot of scenarios).

Doing so is somewhere on the todo list, however, but it’s not a very high priority (you’re probably the fifth person asking thus far, since ~2017 ). As an alternative to ‘calling a lot of callbacks’, however, you could also batch checks, and tell clients their ‘effective’ access in advance, like for example vMenu does.

Moving to the ‘feature requests’ section, however.

---

Addendum: I removed a ‘solution’ marker on my post as it is actually not an implemented feature. A ‘like’ could work as a replacement.