-
-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🍣 New Roles Plugin! #155
base: main
Are you sure you want to change the base?
🍣 New Roles Plugin! #155
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
But I guess I need to add lock for |
I think it should be fine now. Not sure why my git cached showed it that way. |
@ArnavK-09 Alright, so I just checked it out and found a few things to note:
Sorry if I wasn't more clear in the GitHub Issue. I look forward to seeing this fully completed. We've been getting more traffic to our blogs lately so I'd love to write an article about this plugin! (& giving you credit, of course) |
1. I added buttons for "add" "edit" & "delete" earlier! But as I discussed on the official discord server, it would be a ux disaster for users! So we decided to use 2. tysm 👍 |
Fixed |
The role selector one was suggested by the discord community as it is a modern & discord supported option to choose a role! Isn't it would be a mess if user uses reactions in the era of modern dropdowns & button? + It would lack emotes formality as there is only 26 letters or 9 numbers emotes to choose from? |
Modal or Message Collector?
|
well it is already supported, the emote added by the user in the modal is directory interpreted by
|
|
Noted, would update soon after we solve add debate |
I find the current role selectors to be more confusing. They make it seem like it is meant to be used for the end user when it's really not. The earlier implementation was only confusing because it opened up a modal which required the emoji code to be precise, which is not something we can guarantee from anyone to use perfectly.
Is it? Emote reactions are an already-established pattern and used by extremely popular bots such as MEE6 and YAGPDB:
By following this pattern, users are already familiar with what to do, server owners are more likely to accept bots with it, and overall adoption would be easier which is something we definitely need at this stage. New patterns are best done by established players. If you feel this strongly about it, how about letting server admins/mods decide when publishing? Via a button toggle or something of the sort.
I'm not sure what you mean by this. There is a limit of 20 emote reactions to a message, but server limits are much higher than that?
Neither. Per my last message, it should be handled by a separate non-ephemeral message the bot replies with after clicking "Add". The emote is chosen by reacting to it, rather than entering its ID, and the role selector currently in "/roles setup" would be present here. Furthermore, I advise not using the Discord.js "Collector" unless you're willing to set up a revival mechanism. The reason for this is that the collector is stateful and likely to break between bot restarts, requiring you to start a collector again for each and every past instance. The
We shouldn't expect users to know how to enter the correct string in a way that can be interpreted by
Agreed. xD |
Ok so there may be some communication error
+OR
|
Ques: is it ok to use
|
Important How to handle reacted emote on print setup role addition progress embed, that is not available to the client/bot (ie. Another guild emote)? |
Both, but the later is more important. I'm still willing to debate the former for mods/admins, but users should definitely be able to select a role via emotes.
Yes, that is what I mentioned the role selector for. The workflow you described is good, minus the ephemeral part. The message need to be non-ephemeral because Discord does not allow reactions on ephemeral messages. Once reacted, the bot should also clean up that message.
Discord bots are like Nitro users in this regard. If an emote that the bot does not have access to is used, it should remove it automatically as it is not supported. The bot will not be able to print it if it does not have access to it anyway. Similarly, if a normal user reacts to the printed message with an emote that is not one of the options, the bot should automatically remove it. I believe MEE6 works similarly here. |
Hello ! I would like to get back to you on that !, is the plugin done and working ATM, or did you stop working on it ? thanks so much, if you are still working on it, it can contribute to our hacktoberfest event ! |
Although this plugin is ready from my side, but since pmktee asked for some modifications, that are still pending |
Only complete it if you feel like it, there is no rush nor any obligations ^^ we just had another user asking us if they could tackle the issue, but since you were already working on it I wanted to make sure it would not overlap yours, so just let me know (you have plenty of time to decide dw) |
Sure, i unassigned myself from this issue |
Plugin Roles Todo List!
/role setup
/role restrict
Resolves #134