Skip to content
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

Open
dgw opened this issue Mar 20, 2017 · 5 comments
Open

Support "someone kicked ____" factoids #98

dgw opened this issue Mar 20, 2017 · 5 comments
Assignees

Comments

@dgw
Copy link
Collaborator

dgw commented Mar 20, 2017

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 $user 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 $user (most specific)
  2. $nick kicked someone
  3. someone kicked $user
  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.

Per @zigdon below, the implementation must also look up the new kick triggers only if a related config flag is enabled.

@zigdon
Copy link
Owner

zigdon commented Mar 20, 2017 via email

@dgw
Copy link
Collaborator Author

dgw commented Mar 20, 2017

If we going to restore it, it should be guarded in a config flag.

That's fair.

@dgw
Copy link
Collaborator Author

dgw commented Mar 25, 2017

@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).

@zigdon
Copy link
Owner

zigdon commented Apr 13, 2017

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.

@dgw dgw self-assigned this Jul 7, 2017
@dgw
Copy link
Collaborator Author

dgw commented Jul 7, 2017

This just came up in one of my Bucket-serviced channels, so… I guess it's time to put it officially on my plate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants