-
Notifications
You must be signed in to change notification settings - Fork 31
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
Support "someone kicked ____" factoids #98
Comments
We used to have support for that, and decided it was too spammy (especially
that last one). If we going to restore it, it should be guarded in a config
flag.
…On Sun, Mar 19, 2017, 20:44 dgw ***@***.***> wrote:
In addition to the currently supported $nick kicked $user and $nick
kicked someone triggers, users on my instance have proposed use cases for someone
kicked $nick and someone kicked someone.
As an extension to the existing "kicked" triggers, the resolution
hierarchy would go from most to least specific in this order:
1. $nick kicked $nick (most specific)
2. $nick kicked someone
3. someone kicked $nick
4. someone kicked someone (least specific)
Doing it this way essentially adds the new functionality in such a way
that the existing kick factoid types are preferred over the new types.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#98>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AACtVHUBrW4xEe18lzq6L3SD0ohbHWahks5rnfYRgaJpZM4MiATu>
.
|
That's fair. |
@zigdon Would you prefer the default to be on or off? I'd lean toward making the default the current behavior, but only because I wouldn't want to suddenly switch it on for existing instances. Ideally I'd like the default to be enabled for new installs, and disabled for existing…not sure if that's possible with Bucket's current config (IIRC it has no awareness of whether it's been upgraded or created fresh). |
I'd say if it's a plugin, we can have it off by default, and have it added to the sample config, so that new installs will have it on. |
This just came up in one of my Bucket-serviced channels, so… I guess it's time to put it officially on my plate. |
In addition to the currently supported
$nick kicked $user
and$nick kicked someone
triggers, users on my instance have proposed use cases forsomeone kicked $user
andsomeone kicked someone
.As an extension to the existing "kicked" triggers, the resolution hierarchy would go from most to least specific in this order:
$nick kicked $user
(most specific)$nick kicked someone
someone kicked $user
someone kicked someone
(least specific)Doing it this way essentially adds the new functionality in such a way that the existing kick factoid types are preferred over the new types.
Per @zigdon below, the implementation must also look up the new kick triggers only if a related config flag is enabled.
The text was updated successfully, but these errors were encountered: