#Role.permissions#remove

1 messages · Page 1 of 1 (latest)

proud fog
#

Alright

#

So you already have the role instance <guild>.role.cache.get() or <guild.role.fetch().then()

cerulean sphinx
#

I got something like this const role = interaction.guild.roles.cache.find(role => role.name === "Member"); but idk if this is correct

proud fog
#

That should work, but if the member role is static (it doesn't change, or you are only use one guild) you can use the role ID

#

Does that make sense?

cerulean sphinx
#

Yeah I think so. So if the bot is only going to be in my server it can be the role id instead?

proud fog
#

Yeah, that would help, and you will always have the role instance regardless of if the name of the role changed

#

Unless it was deleted

cerulean sphinx
#

In the future I might try to distribute it to other servers and that method may be changed but for rn i just care about it being in my server so the role id can work and I can change the role id later if needed like if it was deleted

proud fog
#

You could have the admin of the server set the ID of the member role so it'll set it in configuration, then call the ID

cerulean sphinx
proud fog
#

Alright

#

I was just typing that but I had to help some other people

# 
const {PermissionFlagsBits} = require('discord.js')

//Get the full list of permissions
console.log(PermissionFlagsBits)

//Remove specific flag
<role>.permissions.remove(PermissionFlagsBits.SendMessages)```
#

@cerulean sphinx

cerulean sphinx
proud fog
#

Oh right sorry

proud fog
cerulean sphinx
#

Whats the "< >" stuff for?

proud fog
#

Im going crazy, cause I told myself that I was gonna add it

proud fog
#

So if your role object was named somerole, you would replace <role> with somerole

cerulean sphinx
proud fog
#

Alright, I'll look into real quick

cerulean sphinx
#

Okay thank you. Im kinda new to javascript and djs so sorry if I misunderstand anything

#

Also the const { PermissionFlagsBits } = require('discord.js'); the permissionflagbits is blue but normally the other variables are green does this mean anything?

proud fog
#

It's just because of how it's called

#

Also it's all good, I love helping people new to discord.js

#

Normally, a variable is called this way:

const variable1 = "Value"
var   variable2 = "Value"
let   variable3 = "Value"```

While discord.js requires you to call the (class?) this way:
```js
const/let/var {PermissionFlagsBits} = require('discord.js')```
#

I'm figuring out the permissions also

#

Um, so the complicated part of permissions is channel overrides

#

so if SendMessages is checked true/false, it overrides the role permission.

cerulean sphinx
proud fog
#

That seems easier, but as you add more channels, eventually you'll get ratelimited

#

You could let the channel inherit permissions by setting channel permissions to null (gray)

proud fog
cerulean sphinx
proud fog
#

Channel/role permission setups are so weird on discord

#

it's hard to explain it, and it's unique to your server because certain servers have verfication

#

Do you understand all of this? If you want I can create a server and explain it that way. Having permissions set to null in channels basically means that you aren't setting it per channel

cerulean sphinx
proud fog
#

Alright

#

Well anyways, setting @everyone's permission node for SendMessages to false means that channels where @everyone's permission to send messages is set to null (not set as true or false, red or green) do not need to be modified

cerulean sphinx
#

Okay I understand I think. So if the channels permission is null or neutral the users roles permissions allow or disallow if they can send messages or not?

proud fog
#

Yes

#

So it's no longer determined by channel permissions, but role permissions

cerulean sphinx
#

I see, alright.

proud fog
#

It's easier to do it by role than channel

cerulean sphinx
#

sorry but I have to go in a minute actually. Can we finish this later?

proud fog
#

Yep

#

I'm actually getting the method on how to set permissions

#

So, I have found an solution, but it also creates another problem.

//Get guild
let guild = client.guilds.cache.get("GUILDID")
let role = guild.roles.cache.get('ROLEID')

//Exclude the permission you want to deny
role.setPermissions([PermissionFlagsBits.ViewChannel]);``` 

This efficiently removes the permission you want to deny, however, it also denies all other permissions other than ViewChannel. The main focus is `<role.setPermissions([])`, the other stuff you can use your own method.

 I have a second method that is slightly more code intensive but should work, I'm testing it right now.
proud fog
# 
//Role & Guild
let guild = client.guilds.cache.get('ID')
let role = guild.roles.cache.get('ID')

//Get role permissions
let permissions = role.permissions

//Loop through those permissions
for(let perm of permissions){
  //Reformats it as a PermissionFlagsBits
  perm = PermissionFlagsBits[perm]

  //This checks if the object is not in the blacklist array, pushes it to the newperms array
  if(!blacklisted.find(a => a === perm)){
    newperms.push(perm)
  }
}
//Sets the new permissions
role.setPermissions(newperms);```
#

Basically, what that does is:

  • Gets the ID of the guild and role (replace with your variables)
  • Gets permission of the role
  • Loop through permissions, checking if it's blacklist & pushing it to the whitelist array
  • Setting the permissions, removing the permission that you wish

All you really have to do there is modify the blacklist array and add valid permissions there

#

If you can find a better solution that, one that doesn't take up too much space and one that makes more sense to you, I would take it.

cerulean sphinx
proud fog
#

It would deny the specific one

cerulean sphinx
proud fog
#

alr

#

i gotta go soon but i'll respond tmrrw