The calculation result of PermissionCalculator#permission? is incorrect

[GrapeColor]

Summary

The calculation result of Discordrb::PermissionCalculator#permission? is incorrect.
According to the Discord specification, if there are multiple roles, "Allow" always takes precedence when overwriting channel permissions, regardless of the priority of the roles.
However, for "permission?", the authority of the upper role takes precedence, and the "Allow" of the lower role is ignored.
Therefore, authority cannot be checked correctly.
It is not possible to identify where the problem is in the library.

---

Environment

Ruby version:

ruby 2.6.5p114 (2019-10-01 revision 67812) [x64-mingw32]

Discordrb version:

C:/Ruby26-x64/lib/ruby/gems/2.6.0/bundler/gems/discordrb-2c2b50e32c05

[GrapeColor]

Channel permission setting

Testing code

require 'bundler/setup'
require 'discordrb'

bot = Discordrb::Commands::CommandBot.new(
  token: "TOKEN",
  prefix: "/"
)


bot.command(:test) do |event|
  p event.server.bot.permission?(:read_messages, event.channel)
end

bot.run

Result

Execute /test on the channel for which the above settings have been made.

false

[swarley]

Sorry that it took a while to get to this one, it appears we discussed this in the channel but I forgot to commit something afterwards.

[GrapeColor]

No problem.
Thank you for your discussion and problem solving.🍰

[GrapeColor]

I'm sorry.
It seems that there are still problems.
For example, when two roles are given, overwriting only one of them seems to make a wrong decision.

Specific example:

Server roles

Channel overwrites

Testing code

require 'bundler/setup'
require 'discordrb'

bot = Discordrb::Commands::CommandBot.new(token: 'TOKEN', prefix: '/')

bot.command(:test) do |event|
  own_member = event.server.bot
  own_member.permission?(:send_messages, event.channel)
end

bot.run

Result

Sending a /test command on that channel will return true.
But, the send_messages permission is actually denied.

[Daniel-Worrall]

This was fixed via shardlab/discordrb@9cc3a26 in the new repo and released in v3.4.0 and can be closed. Thank you for the report.