* 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
* Adding durafmt library and use it from enterprise global relay export
* Allow to specify different server host and server name on smtp connections
* Fixing utils/smtp tests
* 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.
* Emoji validation fails if name exists in system emojis
* Use hashmap instead of array to improve performance
* Changed utils/StringInMap to emoji/isSystemEmoji
* Load system emojis from model/emoji.json
* Added emoji.json from webapp
* Load system emojis from emoji_data.go instead of emoji.json
* Run `gofmt -w model/emoji_data.go`
* 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.
