* don't report an error on plugin activation if already active
* improved plugin logging events
Log an error when a plugin's ServeHTTP fails, or when it unexpectedly
terminates.
Restart a plugin at most three times, allowing its failure to later
bubble up under the "failed to stay running" status.
* clarified plugin activation/deactivation
Avoid repeatedly activating when any configuration bit changes. Improved
logging.
* constrain plugin ids to ^[a-zA-Z0-9-_\.]+$ and enforce minimum length
Previously, the plugin id was used unsanitized to relocate the plugin
bundle, which allowed writing outside the `plugins/` directory by using
an `id` containing `../`.
Similarly, an empty string was accepted as an id and led to unexpected
error messages.
* remove plugins by manifest path, not id
If the id within the manifest ever diverges from the actual plugin
location, it becomes impossible to remove via the API. Instead, if the
plugin is found by id, remove the path containing the manifest.
* ignore plugins with nil manifests
If a plugin was detected, but had a manifest that couldn't be parsed, it
will be left nil but still be listed among the packages. Skip over these
in most cases to avoid segfaults.
* leverage mlog more effectively for plugins
* build issues
* Implementing structured logging
* Changes to en.json to allow refactor to run.
* Fixing global logger
* Structured logger initalization.
* Add caller.
* Do some log redirection.
* Auto refactor
* Cleaning up l4g reference and removing dependancy.
* Removing junk.
* Copyright headers.
* Fixing tests
* Revert "Changes to en.json to allow refactor to run."
This reverts commit fd8249e99bcad0231e6ea65cd77c32aae9a54026.
* Fixing some auto refactor strangeness and typo.
* Making keys more human readable.
This is primarily to unblock the advanced permissions merge. There's
still more work to do if we wanted this to be mainstream, but as it's
mainly for unit tests, I'm just focussing on the minimum.
* MM-10232: improve error handling from malformed slash command responses
Switch to json.Unmarshal, which doesn't obscure JSON parse failures like
json.Decode. The latter is primarily designed for streams of JSON, not
necessarily unmarshalling just a single object.
* rework HumanizedJsonError to expose Line and Character discretely
* MM-10259: pinpoint line and character where json config error occurs
* tweak HumanizeJsonError to accept err first
* Update ISSUE_TEMPLATE.md
Customer wanted us to be more explicit on this page about searching for existing tickets in JIRA vs Github before proceeding to submit a new ticket.
* Update ISSUE_TEMPLATE.md
* Shorten proposed text
* Add user.DeepCopy() function
* Add omit admins/non-admins to WS broadcast and use for updating users
* Updates per feedback and adding unit test for ShouldSendEvent
* Incorporate a Token into the invitations system
* Adding unit tests
* Fixing some api4 client tests
* Removing unnecesary hash validation
* Change the Hash concept on invitations with tokenId
* Not send invitation if it wasn't able to create the Token
* Fixing some naming problems
* Changing the hash query params received from the client side
* Removed unneded data param in the token usage
* unit test TestGet(Search)Replica
This adds partial, testing-focused support for SQLite, as well as removing
some translated log messages that required initializing i18n just for
testing.
* avoid returning master twice when no replicas are configured
* remove duplicate indexes
* unit test GetAllConns
The underlying l4g library is not resilient to filter modifications in
the presence of concurrent goroutines. In particular, it's not safe to
call Close() on filters which might be actively held by a goroutine for
logging.
This change disables all modifications to existing filters once
initialized by the App layer. In practice, we might be able to get away
with some modifications to the existing filters (i.e. changing levels),
but the [golang memory model](https://golang.org/ref/mem) makes no
guarantees that it is safe to do so:
> Programs that modify data being simultaneously accessed by multiple goroutines must serialize such access.
We can solve this holistically by introducing the requisite locking
within our fork of the l4g library. For now, we just disable all
modifications.
WIP Out Of Office
Return error for status command if user status is OOO
Ignore notifications if Out Of Office
Disable AutoResponder if status is set to online
Add test for AutoResponder
DisableAutoResponse when manually setting status
Remove check on status slash command
return early if user does not exists in SendAutoResponse method
Add proper error handling
Add a newline after error handling
Revert back to err == nil in api4/status.go
Remove a.Go when using a.Publish
Add name consistency with the feature auto responder
Last changes for name consistency, also fix failing test with auto_responder
Fix names of functions in auto responder test
Add ExperimentalEnableAutomaticReplies flag
Auto Responder reply to a post
