This wasn't implemented as I'd thought it'd be 😖
preview-alloweddisables the preview functionality for message links that point to my server, when posted to another server. It also disables the expansion of message links entirely on the server the setting is applied on. Even if the message originates from that server, or another.
What I had imagined, and thought was clear from prior discussion of this feature was that the desired restriction would only be when a message link was posted to another server. That is, message previewing, and everything else that
previewenables would remain active on the server that desires this privacy option, but when the target message refers to the server in question, and the link wasn't posted on that server, an expansion wouldn't take place.
Would you please re-open this ticket?
Allow users to designate someone to manipulate their roles from a predefined set selected by the bot owner.
In kinky power dynamics, dominants may be granted the right to enforce behavior modification. On some Discord servers, permission roles are used to broadcast kink roles and such restrictions.
This feature would enable a
@submissiveuser to declare their
@dominant. When the latter user confirms the dynamic, they would then be able to change some of the submissive's roles, such as placing them
@in chastity, etc.
.rolecommand group to facilitate the configuration of this feature, and the assignment of roles by authorized users.
Unless #49 is implemented in tandem with this feature, a separate sub-group would be required for bot owner(s) to configure the module.
grant-configsub-group would allow bot owner(s) to define the role names mapped to the leader and follower user groups, or toggle the feature once it has been configured.
If the configuration record doesn't exist, or the feature is disabled post-configuration, no other commands described below ought to function. Instead, the bot will return an informational error. By default, the feature is enabled when the configuration command is issued.
grant-config @leader-role @follower-role- Sets the
followerattributes of the configuration record to the Discord role IDs. The
stateattribute defaults to
1and does not need to be explicitly set upon record creation.
grant-config enable|disable- Sets the
stateattribute of the configuration record (boolean).
Consent must be obtained by both users interested in the feature. A request is first proposed by the follower of the leader.
Each user's roles are checked to determine if they meet the requirements of using the feature; the proposed leader must have the appropriate role that the bot owner has defined, and the same is true for the initiating follower.
If this check passes, the proposed leader is then pinged with instructions on how to acknowledge or refuse.
Once the relationship has been established, either party may terminate consent, disabling the feature for them. Doing so removes all previously assigned roles from the follower, and notifies both parties of what has occurred.
grant authorize @user- Initiates a request for the
@userto be the requestor's leader. May only be issues by a follower.
grant accept @user- Accepts a pending request by
@user, updating the user relationship DB record's
stateattribute to true. Effectively enables the feature.
grant decline @user- Declines a pending request by
user, removing the DB record.
grant revoke @user- Terminates the initiating user's relationship with
@user, if one already exists. Removes the follower's roles on Discord before deleting the DB record. Rescinds a pending request, if one had been previously placed, deleting the DB record.
Role set definition & user assignment
A new sub-group named
grantwould be created for defining the set of roles that authorized users could select from. The latter functionality would also be achieved with the same commands, but different argument values.
.role grant add|remove|list follower|@user @role [@role, ...]
If this is not possible due to how command group authorization decorators works, the sub-commands could be broken out further, or in-function logic could be used instead of a decorator.
Code path descriptions:
grant add|remove follower @role [@role, ...]- To allow bot owner(s) to define the roles that authorized and consenting users are allowed to assign.
grant add|remove @user @role [@role, ...]- To allow authorized users to manipulate the consenting user(s) roles based on the set defined by the bot owner(s). The user relationship record in DB must exist and have
1to be authorized.
grant list follower- List the roles that have been defined for authorized users to select from.
CREATE TABLE grant_config ( id serial PRIMARY KEY, guild bigint NOT NULL, leader bigint NULL, follower bigint NULL, state smallint NOT NULL DEFAULT 1 CHECK (state = 0 OR state = 1) ); CREATE UNIQUE INDEX idx_guild_leader ON grant_config (guild, leader); CREATE UNIQUE INDEX idx_guild_follower ON grant_config (guild, follower); CREATE UNIQUE INDEX idx_guild_state ON grant_config (guild, state); CREATE TABLE grant_user_relationships ( id serial PRIMARY KEY, config_ref bigint REFERENCES grant_config ON DELETE CASCADE, leader bigint NOT NULL, follower bigint NOT NULL, state smallint NOT NULL DEFAULT 1 CHECK (state = 0 OR state = 1) ); CREATE INDEX idx_leader_follower ON grant_user_relationships (leader, follower); CREATE TABLE grant_roles ( id serial PRIMARY KEY, config_ref bigint REFERENCES grant_config ON DELETE CASCADE, role bigint NOT NULL ); CREATE INDEX idx_configref_role ON grant_roles (config_ref, role); CREATE TABLE grant_follower_assignments ( id serial PRIMARY KEY, pair_ref bigint REFERENCES grant_user_relationships ON DELETE CASCADE, role_ref bigint REFERENCES grant_roles (role) ON DELETE CASCADE, created_at date NOT NULL ); CREATE INDEX idx_pairref_roleref ON grant_follower_assignments (pair_ref, role_ref);
Released with v0.8.0