~erin

Trackers

~erin/web-canary

Last active 6 months ago

#143 Server preference for cross-server previewing 9 days ago

Comment by ~erin on ~nova/fletcher

This wasn't implemented as I'd thought it'd be 😖

Enabling preview and disabling preview-allowed disables 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 preview enables 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?

#50 Role assignment for users in power dynamics 28 days ago

fun added by ~erin on ~luma_inhibitor/cables

#50 Role assignment for users in power dynamics 28 days ago

feature/enhancement added by ~erin on ~luma_inhibitor/cables

#50 Role assignment for users in power dynamics 28 days ago

Ticket created by ~erin on ~luma_inhibitor/cables

Allow users to designate someone to manipulate their roles from a predefined set selected by the bot owner.

#Use Case

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 @submissive user 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 @on denial, @in chastity, etc.

#Implementation Details

Extend the .role command group to facilitate the configuration of this feature, and the assignment of roles by authorized users.

Module configuration

Unless #49 is implemented in tandem with this feature, a separate sub-group would be required for bot owner(s) to configure the module.

The grant-config sub-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.

Commands:

  • grant-config @leader-role @follower-role - Sets the leader and follower attributes of the configuration record to the Discord role IDs. The state attribute defaults to 1 and does not need to be explicitly set upon record creation.

  • grant-config enable|disable - Sets the state attribute of the configuration record (boolean).

Authorization flow

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.

Commands:

  • grant authorize @user - Initiates a request for the @user to 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 state attribute 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 grant would 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 state set to 1 to be authorized.
  • grant list follower - List the roles that have been defined for authorized users to select from.

#Schema Definition

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);

#5 Fix `.color` documentation 28 days ago

on ~luma_inhibitor/cables

REPORTED RESOLVED FIXED

#12 Create color role as the requestor's username 28 days ago

on ~luma_inhibitor/cables

REPORTED RESOLVED FIXED

#47 Upgrade to pycord 2.0 28 days ago

Comment by ~erin on ~luma_inhibitor/cables

Released with v0.8.0

REPORTED RESOLVED IMPLEMENTED

#48 Extend message embeds to threads 28 days ago

Comment by ~erin on ~luma_inhibitor/cables

Implemented as part of #47, and released with v0.8.0

REPORTED RESOLVED IMPLEMENTED

#45 Topic commands 28 days ago

Comment by ~erin on ~luma_inhibitor/cables

Implemented as part of #47, and released with v0.8.0

REPORTED RESOLVED IMPLEMENTED

#42 Bulk role management commands 28 days ago

Comment by ~erin on ~luma_inhibitor/cables

Implemented as part of #47, and released with v0.8.0

REPORTED RESOLVED IMPLEMENTED