An action capable of sending notifications to rooms and users on hipchat. This actions support three types of HipChat APIs:
- `v1` - The (now deprecated) legacy API where a token can be registered at the group level, and the `v1` version of the API can be used. This API only supports room notification (users cannot be notified). multi-room notification is supported.
- `integration` - The basic integration that one can create in HipChat (it is using the `v2` API version), where notifications can be sent to a single room. User notification is unsupported by this API
- `user` - this API uses an API token of a specific user. An admin user can create an API token and configure it to have access to room notification and user private messaging. This API supports multi-room and multi-user notifications.
The settings for `hipchat` are very similar to the `email` infrastructure in nature. It is possible to configure multiple/different hipchat account, each is associated with the api type (a.k.a profile) - can be `v1`, `integration` or `user`, and the respective `auth_token`. When configuring the action in the watch, one can specify what hipchat account they would like to use (when not specifying an account, the `default_account` will be used). Each account can also specify its own unique `host`/`port` for the hipchat server - for full flexibility.
Closeselastic/elasticsearch#462
Original commit: elastic/x-pack-elasticsearch@9d9ee13542
In order to adhere to our elasticsearch core release script,
this script allows you to use a staging release to build x-plugins
against it, and then upload the created artifacts to the same
s3 bucket, so people can actually test the whole package of core
plus x-plugins.
Please read the documentation in the RELEASE.md document to understand
when to run which script!
Original commit: elastic/x-pack-elasticsearch@a43ce25b6f
PreProcessModule was an alternate way to customize another module's
behavior inside plugins. The preferred (and only in the future) way to
do this is with onModule in the plugin itself. This change moves the
only two remaining users of PreProcessModule to do so in their
respective plugins. The use case was adding roles for shield
authorization, but these roles were really static, so there was no
reason they could not be configured up front.
Original commit: elastic/x-pack-elasticsearch@e67ac2dcb6
This adds the extension points necessary to enable a user to write a elasticsearch plugin
that can integrate with Shield and add a custom authentication realm. For the most part,
the work here just exposes the existing interfaces we have been using for Realms and
factories to create realms. An additional interface was added to allow for a custom
authentication failure handler to be used. This was needed to support use cases like SSO
and Kerberos where additional headers may need to be sent to the user or a different
HTTP response code would need to be sent.
Relates to elastic/elasticsearch#24
Original commit: elastic/x-pack-elasticsearch@13442e5919
SpawnModules will be going away very soon as part of
elastic/elasticsearchelastic/elasticsearch#12783. This change removes its use from all
x-plugins.
Most spawnmodules uses here were to either collect a number of modules
into one (so the modules were just moved up into the plugin itself), or
to spawn a module which interacted with an extension point from ES. This
change moves those, as well as most uses of PreProcessModule, to use
onModule.
Original commit: elastic/x-pack-elasticsearch@6430e35379
Depending on the returned value at the time the test is executed, it can be recognized as int, or long or whatever.
Original commit: elastic/x-pack-elasticsearch@0b73838f30
jaymode
uboness
Tanguy Leroux
Areek Zillur
Martijn van Groningen
Alexander Reelsen
Simon Willnauer
Robert Muir
Ryan Ernst
debadair
David Pilato
Adrien Grand