Open 23nd opened 6 years ago
@Navi-King For clarification, you want me to do the following?
GlobalWhiteListSet
command that adds a new entry into the WhiteListSet table
.gwl add/remove PatronTier1
create/deletes a whitelist named PatronTier1 (must be unique)GlobalWhiteList
command that adds a Server/Channel/User ID to the WhiteListItem table, and adds a relationship to the WhiteListItemInSet table to link the server/channel/user to a specific whitelist set name
.gwlu PatronTier1 USER_ID
add/removes a specific user to the PatronTier1 whitelist.gwlc PatronTier1 CHANNEL_ID
add/removes a specific channel to the PatronTier1 whitelist.gwls PatronTier1 SERVER_ID
add/removes a specific server to the PatronTier1 whitelistWhiteList
command that links a whitelist set to a specific command or module, and adds it as an entry in BlockFreeCmdOrMdl table
.gwmod ModuleName add/remove PatronTier1
adds or removes the entry linking PatronTier1 whitelist to ModuleName.gwcmd CommandName add/remove PatronTier1
adds or removes the entry linking PatronTier1 whitelist to CommandNameListWhiteListNames
command that lists all whitelist set namesListWhiteListMembers
command that lists all IDs of members belonging to a specific whitelist set
.lwlm PatronTier1 server
lists all server IDs belonging to the PatronTier1 serverTryBlockEarly()
in BlackListService.cs
since we don't want to give power to blacklisted users/channels/serversTryBlockLate()
in GlobalPermissionService.cs
to return false if the server/channel/user belongs to a whitelist linked to the given command/module(Navi) I think it makes sense. Basically you’re mimicking the blacklist structure but using it to whitelist. You’re verifying that blacklisted users can’t use commands in whitelisted servers/channels, but making sure that whitelisted users can still use blacklisted commands?
(Katsu) Well commands aren’t blacklisted. Servers/Channels/Users are blacklisted. Whitelisted servers/channels/users can use globally disabled commands/modules, but whitelisted servers/channels/users are still disabled from using commands when blacklisted blacklist is all-or-nothing (all commands disabled) for specific users/channels/servers(edited) and yes, blacklisted users cannot use commands in whitelisted servers/channels So i won’t be modifying any blacklist stuff, just using it as a structure for whitelist and modifying the global command/module stuff perhaps whitelist is a misnomer
(Navi) Ok so basically the whitelist I want should override global permission but not blacklist
(Katsu) yeah, or actually, it’s also called “blocking”. so unblocking the blocking
(Navi) But yeah basically I want “blocked” commands able to be used by “unblocked” users Obviously the command to modify that should be bot owners only and bot owners should automatically be able to use any blacklisted command anyway. Or at least added to the unblocked list by default
When all items have been checked off, this issue may be closed.
Note that this probably follows a MVC paradigm, and that the models should be written in code, migrations generated by some sort of dotnet command, and database tables generated at runtime.
Id
to a WhiteListSet Id
WhiteListSetId
for linking a whitelist set to a specific command or moduleEach of these should have [NadekoCommand, Usage, Description, Aliases]
attributes, and be added to either GlobalPermissionsCommands.cs or a new WhitelistCommands.cs in the Permissions module.
.gwl add/remove PatronTier1
create/deletes a whitelist named PatronTier1 (must be unique)[OwnerOnly]
attributesrc\NadekoBot\_strings\cmd\command_strings.json
src\NadekoBot\_strings\ResponseStrings.en-US.json
.gwlu PatronTier1 USER_ID
add/removes a specific user to the PatronTier1 whitelist.gwlc PatronTier1 CHANNEL_ID
add/removes a specific channel to the PatronTier1 whitelist.gwls PatronTier1 SERVER_ID
add/removes a specific server to the PatronTier1 whitelist[OwnerOnly]
attributesrc\NadekoBot\_strings\cmd\command_strings.json
src\NadekoBot\_strings\ResponseStrings.en-US.json
.ubm ModuleName add/remove PatronTier1
adds or removes the entry linking PatronTier1 whitelist to ModuleName.ubc CommandName add/remove PatronTier1
adds or removes the entry linking PatronTier1 whitelist to CommandName[OwnerOnly]
attributesrc\NadekoBot\_strings\cmd\command_strings.json
src\NadekoBot\_strings\ResponseStrings.en-US.json
.lwl
[OwnerOnly]
attributesrc\NadekoBot\_strings\cmd\command_strings.json
src\NadekoBot\_strings\ResponseStrings.en-US.json
.lwlm PatronTier1 server
lists all server IDs belonging to the PatronTier1 server[OwnerOnly]
attributesrc\NadekoBot\_strings\cmd\command_strings.json
src\NadekoBot\_strings\ResponseStrings.en-US.json
.lub PatronTier1
lists all commands/modules unblocked for PatronTier1 members[OwnerOnly]
attributesrc\NadekoBot\_strings\cmd\command_strings.json
src\NadekoBot\_strings\ResponseStrings.en-US.json
.cmwl
lists all whitelist sets that include the author's user ID.cmwl user USER_ID
lists all whitelist sets that include USER_ID.cmwl channel CHANNEL_ID
lists all whitelist sets that include CHANNEL_ID.cmwl server SERVER_ID
lists all whitelist sets that include SERVER_ID[OwnerOnly]
or [RequireContext(ContextType.Guild)]
attributesrc\NadekoBot\_strings\cmd\command_strings.json
src\NadekoBot\_strings\ResponseStrings.en-US.json
Unblocked
properties to the class and constructor (see BlacklistService.cs for ideas)
TryBlockLate()
to return false
if the server/channel/user belongs to an Unblocked list linked to the given command/moduleStatus update: pretty much all the commands for adding/removing and creating/deleting have been implemented, along with some info commands to list members and unblocked cmds/mdls for each list.
What's left:
For ResetGlobalPerms, the existing implementation leaves unwanted data in the database. To avoid messing with it, I'll implement a separate ResetGlobalWhitelist and ResetGlobalUnblocked for totally clearing all GlobalWhitelist records and UnblockedCmdOrMdl records (and their relation table records).
Also note that I cannot unblock Custom Reactions (even though they can be added to a whitelist), because NadekoBot does not block them in the CustomReactionsService.TryExecuteEarly
behavior (even though they can be added to global permissions via gcmd
).
Note 2: Any changes made in the database to either BlockedCmdOrMdl or UnblockedCmdOrMdl may cause the global permissions to be out of sync with the database. A restart will be required to re-sync global permissions, should you find yourself modifying the database directly.
I could reload the GlobalPermissionService via bot command, but that may introduce a moment of vulnerability without any working permission checks.
I also tried to modify the internal hashsets of (Un)BlockedCommands/Modules to sync them with the database, but unfortunately those hashsets are readonly and I don't want to overrule that decision at this time.
This is awesome. We do still need to move it to its own module probably though since keeping it in permissions messes with the commands that general users should be able to use. Also it will help future proof it against upstream code changes.