You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There needs to be a query that allows to get all users, but filtered by guild id. This will require a few features and changes to models and graphql queries.
Reasoning
My logic for this feature is that there should be some ease-of-use in obtaining all the users in a guild (that have opted in to a service that utilizes guild id) for a discord bot, rather than requiring the client to make the filter. This is also a large privacy concern. I.e if a user adds a timezone, that timezone should only be available in servers the user has enrolled in. A user should be able to add a timezone to their profile for use in server A, but not need to worry about server B (or any other server with friendo bot) having access to that private information. But a user should be able to enroll in these other servers and have that guild id added.
I believe this could best be done as a list of guild ids, where each guild id is only added if the user has opted in to any private-information tracking (such as timezone), meaning all guild ids represent permission to share that info on those servers. With that said, it might make sense to have a table of user's related guilds where each guild has a list of services opted in, or perhaps a bool for whether or not they are opted in for private info sharing on that server.
Requirements
Users will have at least one guild id after they have enrolled in a service that requires it
Client should be able to request a response of all users that contain a specific guild id
API should reject, or make information completely inaccessible when requesting private information on a server for which the user has not enrolled into sharing private information (see example in "reasoning")
It may be prudent to to move the timezone_name from a user, to a guild model that is associated with the user. Making it easier to keep sensitive information hidden.
Summary
This is a large, but necessary change that may require reworking of multiple systems. Most of the infrastructure is there already, so this should be fairly simple to implement, but the logic needs to be carefully thought out.
The text was updated successfully, but these errors were encountered:
What
There needs to be a query that allows to get all users, but filtered by guild id. This will require a few features and changes to models and graphql queries.
Reasoning
My logic for this feature is that there should be some ease-of-use in obtaining all the users in a guild (that have opted in to a service that utilizes guild id) for a discord bot, rather than requiring the client to make the filter. This is also a large privacy concern. I.e if a user adds a timezone, that timezone should only be available in servers the user has enrolled in. A user should be able to add a timezone to their profile for use in server A, but not need to worry about server B (or any other server with friendo bot) having access to that private information. But a user should be able to enroll in these other servers and have that guild id added.
I believe this could best be done as a list of guild ids, where each guild id is only added if the user has opted in to any private-information tracking (such as timezone), meaning all guild ids represent permission to share that info on those servers. With that said, it might make sense to have a table of user's related guilds where each guild has a list of services opted in, or perhaps a bool for whether or not they are opted in for private info sharing on that server.
Requirements
timezone_name
from a user, to a guild model that is associated with the user. Making it easier to keep sensitive information hidden.Summary
This is a large, but necessary change that may require reworking of multiple systems. Most of the infrastructure is there already, so this should be fairly simple to implement, but the logic needs to be carefully thought out.
The text was updated successfully, but these errors were encountered: