When the AD/LDAP User Filter is too permissive, multiple user objects with the same Email Attribute may be returned. When this happens, and the Username Attribute is not present on the returned value, Mattermost may reset the username of the existing user with the same email address to a random string. This repeats every 60 minutes (or whatever the Synchronization Interval is set to).

For example, if two LDAP objects are returned:
{ userclass=contact, email=myusername@example.com }
{ userclass=user, sAMAccountName=myusername, email=myusername@example.com }

In this case, Mattermost may cause username@example.com's account to have its user id changed to a random 37-digit base-36 number

When this occurs, tracking the problem down is very difficult. The only information in the logs is that the username for several accounts changes to a new random value every hour.

To make this simpler, Mattermost's logs should indicate when the AD/LDAP system returns duplicate entries for the ID attribute.

(Mattermost Support suggested I file this as a Feature Request, although it feels like a bug)

Add a way to customize the display of the chat in the web interface. Currently a single message takes up two lines of text. If each message could be formatted as desired, the layout could be tailored to each users preference.

For example (with overly descriptive variable names):
%SENTTIME%| %SENDER%> %MESSAGE%
Would result in:
15:56| Kristian> Hello world!

To build the current view, you could do:
%AVATAR% %SENDER% %SENTTIMEAGO%\n%MESSAGE%

Or something like that.

As a long time IRC user, I feel that the WebUI for mattermost uses way too much space for a simple chat messages. With customized layout, it would also be possible to also show the exact time of a message, rather than "x ago" which I find extremely unprecise. :-)

As administrator I want to restrict notification messages sent from my self-hosted mattermost server to be GPG signed and encrypted.

That means, if a user hasn't uploaded a GPG public key to his account, notifications sent to him only contain some metadata or nothing at all.
If a user has uploaded a GPG public key, then the notification message is encrypted for him as receiver, so only he can read it.
The notification message shall be signed in any case with the private key that I configured in my mattermost server.

Motivation: transport layer security between the mattermost server and clients is a great thing for transfering confidential information, however, if the receiver happens to be offline/away and notifications are configured to contain the content of the message it results in a leak of this sensitive information because the data lands in plain text on foreign mail servers.

If a user is sending highly sensitive information over a Mattermost deployment, having it traverse Apple's and/or Google's servers unencrypted en route to a mobile device may not be acceptable. At the same time, configuring the server to exclude the message body removes a significant amount of potentially-valuable context from the notification.

The conflict between these concerns could be resolved by having the Mattermost server encrypt mobile notifications with a per-device key prior to submission, and having the mobile app decrypt the notification before presenting it to the user.

This can be done on iOS with a Notification Service Extension: https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ModifyingNotifications.html
This can be done on Android with FCM data payloads: https://firebase.google.com/docs/cloud-messaging/android/receive

We are a .org wishing to implement Mattermost.

We would like only a specific group of "internal" users to be allowed to access the server from outside the firewall. In addition, we would also like a specific group of external clients to be able to access the server through the mobile app.

I understand one method is to use a VPN. However, an additional app to put on someone's device may be a burden.

The Novell/Micro Focus Product Webaccess has a feature that allows the admin to specify users via an .xml file.

A snippet:

"Controlling WebAccess Usage:

You can control which users can use WebAccess to access their GroupWise mailboxes. By default, all GroupWise users can use WebAccess.

You can control access based on the domain or post office where the user’s mailbox is located. You can control access for related users based on groups, and you can control access for individual users.

Access control is established through the gwac.xml file, located in the same folder with the webacc.cfg file.

The default gwac.xml file illustrates the following options:

<!-- To allow access to all EXCEPT a few, use this technique. -->
<!--
<gwac access="prevent">
<domain name="domain1" />
<postOffice name="po2.domain2" />
<user name="jdoe.po3.domain3" />
<distributionList name="helpdesk.po4.domain4" />
<resource name="confroom.po4.domain4" />
</gwac>
-->

<!-- To prevent access to all EXCEPT a few, use this technique -->
<!--
<gwac access="allow">
<domain name="domain1" />
<postOffice name="po2.domain2" />
<user name="jdoe.po3.domain3" />
<distributionList name="helpdesk.po4.domain4" />
<resource name="confroom.po4.domain4" />
</gwac>
-->
You can use any ASCII text editor that you prefer to edit the gwac.xml file.

Open the gwac.xml file in a text editor.

Typically, you use the gwac.xml file to override the default of allowing all users to use WebAccess.

Remove the comment marker lines (<!-- and -->) around the section that you want to use.

(Optional) Under the <gwac access="prevent"> line, create one or more lines to prevent users in one or more domains from using WebAccess, for example:

<domain name="provo5"/>
<domain name="provo6"/>
(Optional) Create one or more lines to prevent users in one or more post offices from using WebAccess, for example:

<postOffice name="interns.provo1"/>
<postOffice name="temps.provo1"/>
Specify the post office in post_office.domain format.

(Optional) Create one or more lines to prevent users in one or more groups from using WebAccess, for example:

<distributionList name="webaccessdenied.admin.provo1"/>
Specify the group in group.post_office.domain format.

Using one or more groups is the most flexible approach to access control for WebAccess. The group belongs to a specific post office (for example, the one you belong to), but it can include GroupWise users located anywhere in your GroupWise system. By using a group, you can easily modify access control for specific users by modifying the group in the GroupWise Admin console, rather than needed to modify the gwac.xml file whenever access control changes are needed. For more information about groups, see Section 56.0, Creating and Managing Groups.

(Optional) Create one or more lines to prevent specific users from using WebAccess, for example:

<user name="sjones.interns.provo1"/>
<user name="gbock.interns.provo1"/>
(Conditional) If you want to prevent most users and allow only specified users, use a <gwac access="allow"> line instead of a <gwac access="prevent"> line.

Save the gwac.xml file."

Please consider.

Original Request:
http://forum.mattermost.org/t/restricting-users-from-accessing-mattermost-outside-firewall/2617

as we like the style of discussion coming up to several topics, a lot customers we work with, make us work with an NDA. So we are not allowed to discuss work related stuff with people, that did not sign this NDA. Ok. We could go with Private Groups. BUT: this is invite only. Sometimes it would be helpful to be able to "see" that there are several topics that might be of my intrest, so i would like to ask the admin to let me join. So I would like to have different "Channel Modes" like : administrate channe users, show Channel in Channel list etc.