* 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.
* 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
* 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
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
* MM-9849 Added tracking of which settings are set through environment variables
* Removed old version of viper
* Added forked version of viper
* Fixed unit tests
* Fixed more unit tests
* Removed copy from App.GetEnvironmentConfig
* add CUD support for channel members via plugins
This effectively exposes AddChannelMember, UpdateChannelMemberRoles,
UpdateChannelMemberNotifyProps and LeaveChannel via the plugin API.
It also modifies the semantics of AddChannelMember to explicitly allow
for an empty user requestor, left as such for now via the plugin API.
* change the signature of AddChannelMember to accept a channel id instead of a channel
* Add command and store changes to allow mute toggling
* Change channel muting to use ChannelMember notification structure
* Suppress email and push notifications for a muted channel
* Make i18n keys issue-compliant
* Add notification-cache handling for channel-muting
* Add channel handle for channel-muting slash-command
* Add unit test for mute command
* Merge branch 'master' into PLT-4340
# Conflicts:
# app/notification.go
* Fix issue that command_mute responses will be overwritten
* Fix i18n key for channel muting
* Apply new Provider Interface to MuteCommand
* Migrate mute notification property to mark_unread
PLT-4340
* Make some i18n improvements for command_mute
PLT-4340
* Remove de.json translations
* Prevent push notifications when channel is muted
* Treat Group messages like Direct messages
* Fix unit test
* Send WS event when the channel member notify props changed
* MM-9661: rename POST_MESSAGE_MAX_RUNES to \0_v1
* MM-9661: s/4000/POST_MESSAGE_MAX_RUNES_V1/ in tests
* MM-9661: introduce POST_MESSAGE_MAX_RUNES_V2
* MM-9661: migrate Postgres Posts.Message column to TEXT from VARCHAR(4000)
This is safe to do in a production instance since the underyling type is
not changing. We explicitly don't do this automatically for MySQL, but
also don't need to since the ORM would have already created a TEXT column
for MySQL in that case.
* MM-9661: emit MaxPostSize in client config
This value remains unconfigurable at this time, but exposes the current
limit to the client. The limit remains at 4k in this commit.
* MM-9661: introduce and use SqlPostStore.GetMaxPostSize
Enforce a byte limitation in the database, and use 1/4 of that value as
the rune count limitation (assuming a worst case UTF-8 representation).
* move maxPostSizeCached, lastPostsCache and lastPostTimeCache out of the global context and onto the SqlPostStore
* address feedback from code review:
* ensure sqlstore unit tests are actually being run
* move global caches into SqlPostStore
* leverage sync.Once to address a race condition
* modify upgrade semantics to match new db semantics
gorp's behaviour on creating columns with a maximum length on Postgres
differs from MySQL:
* Postgres
* gorp uses TEXT for string columns without a maximum length
* gorp uses VARCHAR(N) for string columns with a maximum length of N
* MySQL
* gorp uses TEXT for string columns with a maximum length >= 256
* gorp uses VARCHAR(N) for string columns with a maximum length of N
* gorp defaults to a maximum length of 255, implying VARCHAR(255)
So the Message column has been TEXT on MySQL but VARCHAR(4000) on
Postgres. With the new, longer limits of 65535, and without changes to
gorp, the expected behaviour is TEXT on MySQL and VARCHAR(65535) on
Postgres. This commit makes the upgrade semantics match the new database
semantics.
Ideally, we'd revisit the gorp behaviour at a later time.
* allow TestMaxPostSize test cases to actually run in parallel
* default maxPostSizeCached to POST_MESSAGE_MAX_RUNES_V1 in case the once initializer panics
* fix casting error
* MM-9661: skip the schema migration for Postgres
It turns out resizing VARCHAR requires a rewrite in some versions of
Postgres, but migrating VARCHAR to TEXT does not. Given the increasing
complexity, let's defer the migration to the enduser instead.
* If Forward80To443 is true, but not configured to listen on 443, fail to start the server with an error message.
* If Forward80To443 is false and LetsEncrypt is true, fail to start the server with an error message.
* log the config file path used by the server on startup
* return an err if the bulk import command fails
* log the underlying errors that occur when importing
The code assumed all errors meant a missing resource, but it's possible
something else is at fault. Including the error helps pinpoint that more
readily.
* Add supported timezones into config
Remove Timezone list creation in favor of timezone from configs
Add Timezone field to Users table
Clean up format of SupportedTimezones in config
* Remove unwanted change
* Add test for updating user timezone
* Add empty map[string]string if Timezone is null
* Add EnableTimezoneSelection config
* Revert back to map[string]string for ClientConfig
* Refactor SupportedTimezones into timezones.json
* Include timezones.json in TestConfigFlag
* Add timezone api endpoint
* Bump varchar size to 256 and setMaxSize in user_store
* Refactor LoadConfig to LoadConfig and LoadTimezoneConfig
* Remove unnecessary argument in LoadConfig, mail_test
* Add test for timezone endpoint
* Add license header
* Refactor timezones endpoint to system.go
* Add system base route to timezone endpoint
* db timezone upgrade in db v4.9
* Avoid saving SupportedTimezones to config.json
* Add timezonePath support in config
* Remove EnableTimezoneSelection from config
* Use return statement without return parameter
* Refactor test for SupportedTimezones
* Check for supportedTimezone != nil instead of using len
* Decouple SupportedTimezones out of Config
* Fix failing test
* Add LastTeamIconUpdate back in upgrade.go
* Write timezone config in config_flag_test
* Add code fallback for default timezone support
* failing to find i18n shouldn't segfault
The server was trying to handle the fact that it couldn't find the i18n
directory, by emitting a translated log message...
* fix utils.FindDir
The attempts to find the directory in the parent or grandparent directory
don't work if the current working directory was inside `enterprise`, with
`enterprise` itself being a symlink as per the usual developer setup.
Recurse to the root of the filesystem, cleaning the path along the way
to work around this limitation (and allow tests to be run from an
arbitrarily deep nesting level.)
Fix corresponding usages to employ filepath.Join.
* failing to find html templates shouldn't segfault
* fail fast if the test user cannot be created
* rework utils.FindDir to retain backwards compatibility
