The permission management for roles as well as categories and textChannels / voiceChannels does not function correctly. After a fair bit of research with the help of another discord user, it appears to be an issue with how the permission enums as well as everything further down the line is handled.
Should be
return 2ULL^n
Changing it to this however causes a problem here as cdata is not recognized by the Resolver.
|
function Resolver.permission(obj) |
And when this function is expanded to support cdata, there is still the problem that cdata cannot be a table key.
Assuming the data type is preserved for permissions, changing the flag function in the enums.lua causes problems in other areas as the gatewayIntents starts to throw errors as well when changing it to return 2ULL^n - This I haven't looked into much further.
--
Stuff that I tried to do that lead to discovering the issue:
local tBotclass = require("../botinfo")
local enums = tBotclass.tDiscordia.enums.permission
local obj_Guild = message.guild
local obj_Role_Everyone
for _,v in pairs(obj_Guild.roles) do
if v.name == "@everyone" then
obj_Role_Everyone = v
break
end
end
local obj_Category = obj_Guild:createCategory("test-category-ignore")
local obj_Permissions = obj_Category:getPermissionOverwriteFor(obj_Role_Everyone)
obj_Permissions:denyAllPermissions() -- @everyone has no rights here!Do note that I removed all error handling here to make this code easier to understand.
The code above results in this:
denyAllPermissions is clearly not working correctly.
When I attempt to deny specific permissions like so:
obj_Permissions:denyPermissions(enums.readMessages,enums.changeNickname,enums.sendMessages,enums.embedLinks,enums.attachFiles,enums.addReactions,enums.useExternalEmojis,enums.readMessageHistory,enums.useSlashCommands)
This happens:
A lot of permissions are being denied that I did not choose, this also happens when I use allowPermissions instead, but it allows all of these permissions instead of denying them (duh)
--
I don't know the full extent of the issue, I'm not too familiar with how Discordia works internally so this is unfortunately all the information I can provide about this issue.
One thing that I can safely say though is that ULLs (somehow) work perfectly fine on my pi which is running a 32Bit system. (0ULL - 1) returns 18446744073709551615 which is precisely the 64bit limit for long integers.
The permission management for roles as well as categories and textChannels / voiceChannels does not function correctly. After a fair bit of research with the help of another discord user, it appears to be an issue with how the permission enums as well as everything further down the line is handled.
Discordia/libs/enums.lua
Line 158 in 899a8d4
Should be
return 2ULL^nChanging it to this however causes a problem here as cdata is not recognized by the Resolver.
Discordia/libs/client/Resolver.lua
Line 156 in 899a8d4
And when this function is expanded to support cdata, there is still the problem that cdata cannot be a table key.
Assuming the data type is preserved for permissions, changing the flag function in the enums.lua causes problems in other areas as the gatewayIntents starts to throw errors as well when changing it to
return 2ULL^n- This I haven't looked into much further.--
Stuff that I tried to do that lead to discovering the issue:
Do note that I removed all error handling here to make this code easier to understand.
The code above results in this:
denyAllPermissions is clearly not working correctly.
When I attempt to deny specific permissions like so:
obj_Permissions:denyPermissions(enums.readMessages,enums.changeNickname,enums.sendMessages,enums.embedLinks,enums.attachFiles,enums.addReactions,enums.useExternalEmojis,enums.readMessageHistory,enums.useSlashCommands)This happens:
A lot of permissions are being denied that I did not choose, this also happens when I use allowPermissions instead, but it allows all of these permissions instead of denying them (duh)
--
I don't know the full extent of the issue, I'm not too familiar with how Discordia works internally so this is unfortunately all the information I can provide about this issue.
One thing that I can safely say though is that ULLs (somehow) work perfectly fine on my pi which is running a 32Bit system. (0ULL - 1) returns 18446744073709551615 which is precisely the 64bit limit for long integers.