A248 / LibertyBans

The be-all, end-all of discipline.
https://ci.hahota.net:8443/job/LibertyBans/
GNU Affero General Public License v3.0
165 stars 40 forks source link

Command aliases have no means of resolving conflicts with other plugins #239

Open accLarson opened 10 months ago

accLarson commented 10 months ago

LibertyBans Version

LibertyBans 1.1.0-RC1

I have confirmed that ...

Platform

Spigot/Paper

Description

With config.yml ConfigurationSection:commands.aliases set as follows, when an operator types /unban <player> the essentials executing occurs. It was my understanding that whatever aliases are in this config should be top priority.

commands:
   # What commands should be registered as aliases for libertybans commands?
   # For each command listed here, '/<command>' will be equal to '/libertybans <command>'
  aliases:
    - 'ban'
    - 'unban'
    - 'banlist'
    - 'history'
    - 'blame'
    - 'alts'
    - 'accounthistory'
    - 'expunge'
A248 commented 10 months ago

Unfortunately, the Bukkit API doesn't provide a means of defining command priorities. There is no good way for us to forcibly override other plugins' commands without special-casing Essentials or other hacky workarounds.** It is entirely arbitrary, therefore, whether LibertyBans' or Essentials' command is chosen.

Nonetheless, this behavior is so commonly reported by users that it deserves to be better documented. It is the number one reason users come to ask for support. To avoid arbitrary behavior, command conflicts should be resolved through one of multiple means:

  1. Configuring the server's commands.yml.
  2. Disabling the command in Essentials' disabled-commands config option.
  3. Using an alias plugin to reroute the command. Many alias plugins can intercept commands before they reach plugins.
  4. Improve Essentials' command system in other ways, such as by not registering commands at all. May involve contributing to Essentials' codebase to fix their registration systems.
  5. Install LibertyBans on the proxy, if applicable.

These options should be documented on a wiki page so that we can refer users to them without having to reiterate the state of command handling ad infinitum. I am therefore marking this issue as "documentation" so that someone can contribute a wiki page for us.

**I will note that AdvancedBan took a different approach. Whereas LibertyBans has a no-hacks and reliable-software policy, AdvancedBan has more of a "just make it work" policy. Hence Leoko's decision on the matter when I was a contributor to AdvancedBan and raised the issue there.

accLarson commented 1 month ago

The commands with libertybans and essentials seem to be feuding more than when I initially posted this issue. For example: https://github.com/A248/LibertyBans/issues/271 posted by @Z3r0xh

The bandaid solution is to use commands.yml and specify in this notation:

ban:
- libertybans ban $1-
alts:
- libertybans alts $1-
history:
- libertybans history $1-

etc

Notice the lack of colon between "libertybans" and the command. The format libertybans:ban $1- did not work in my case.

Z3r0xh commented 1 month ago

Los comandos con libertybans y essentials parecen estar más enfrentados que cuando publiqué este problema inicialmente. Por ejemplo: #271 publicado por@Z3r0xh

La solución provisional es utilizar commands.ymly especificar en esta notación:

ban:
- libertybans ban $1-
alts:
- libertybans alts $1-
history:
- libertybans history $1-

etc.

Observe la falta de dos puntos entre "libertybans" y el comando. El formato libertybans:ban $1-no funcionó en mi caso.

At the time I tried both forms both with the ":" and without.

The temporary solution is to edit the Essentials commands in plugin.yml and removing those related to bans, mutes, kics, etc.

accLarson commented 1 month ago

I see. Strange, I didn't have to modify the plugins.yml file.