sscpac / chat-locker Goto Github PK

We guys seem very active and developing some very important features we have been missing on the Rocket.Chat main project. We'd love to have you guys on the team, or at least help you push more PRs to the main project to keep them more in sync :)

When in a direct message or private group, clicking the security banner causes the relabel dialog to slide out on the left. However, public channels do not get (re)labeled. But when in a public channel, the banner is still clickable, and doing so causes the left pane to freeze up so you can't select other rooms, etc.

When this happens, you can still chat in the current channel. Also, the left pane can get "unfrozen" by clicking the user details box on the top-left to open and close the menu for setting status, settings, etc.

As room owner, I can't find a way to remove a channel member. From what I can tell, only the user can remove themselves from the room. See RocketChat#168

Do we remove direct messages?

When a channel/group/direct message is marked as "favorite" and selected, it is highlighted in both the "favorites" and its channel/group/direct message section.

Is that something we want?

Include:

• Build server settings (Travis-CI), and code coverage reports.
• Name changes
• Remove old logo, demo info, any links/references to RocketChat
• Add our system background (5200.01V2).

Does our LDAP datastore specify an admin field? We can't create a local user like RocketChat does (see initialData) because we authenticate against LDAP and the user doesn't exist in LDAP.

The other option is to specify a LDAP username in default settings similar to our LDAP configuration.

To replicate:

1. login and create a private group
2. expand the flex-tab on right that displays private group members.
3. try to add a user (that's not a member). no names are returned.

Related to #63.

When creating a direct message, any updates to the 'with whom' field that don't involve selecting an entry from the drop-down dialog do not stick.

Steps to reproduce:

1. Create a direct message
2. In the 'with whom' dialog, select any user
3. Now, put the cursor in the 'with whom' dialog and make a small modification (e.g., hit backspace to remove a few letters from the name)
4. Hit the 'Save' button - a new direct message is created with the user selected in step (2), rather than the value set in step (3)

Expected behavior:
A direct message should be created with exactly the text that appears in the 'with whom' field, so as to not be confusing to the user. In the case that the input text does not correspond to an actual user in the system, and error should be returned.

Found by Brent:
When labeling a room, if conflicts exist such that the security label entries in the drop down selector (e.g., the drop-down list for SAP labels) show up as 'red', indicating that a current room member can't access it, and then, without closing the drop-down dialog, a selected label is removed, the styled entries in the drop down (e.g., the 'red' ones) get reverted to normal style. When the drop down is closed and reopened, the entries are once again styled correctly to indicate a conflict.

Steps to reproduce:

1. Log in as a user with access to some security labels (e.g., 'testadmin')
2. Begin creating a private group
3. Add a user without access to some security labels (e.g., 'testuser3')
4. Select one of the SCI/SAP labels (should show as red to indicate other user can't access)
5. Open the drop-down menu again for the same type of label
6. The open list should show other options that are styled red
7. Without closing the list, cancel the selection of the label selected in step (4)
8. The red entries in the drop down menu erroneously revert to their original (non-red) style

Update latest from RocketChat.

direct chats, channels, group chats.

Currently, RocketChat doesn't display offline members in a channel/private group in the right flex tab. However, it's confusing when an offline user is added and they don't appear in the members list. Also, our end users will probably want to see all members displayed. If they are offline or invisible, then just grey them out.

To replicate;

1. Login as testuser1
2. create a online custom status message
3. view users collection. status message saved in profile.statusMessages
4. logout and login again as testuser1
5. view users collection. status message field is missing.

At initial startup/login, we retrieve the user's information from LDAP and do an upsert with the whole user object. chat-locker specific properties at the root level (like status field) are not overwritten. However, child objects (like profile) clobber existing profile objects.

To fix, we need to do one of the following:

1. store chat-locker specific properties at the root level
2. individually declare fields to overwrite
3. store chat-locker fields in child object with different name then child objects from LDAP

When labeling a message, selecting a new access should make the users greyed out when trying to add more users....and vice versa.
It should also change color of existing users or labels (sci / sap) that are not able to be seen by all.

Acceptance Criteria:

• User can have multiple direct messages with different classifications with someone else.
• Display under 'Direct Messages' needs to show label. Possibly partial label with full label visible over hover.

Mouse over your message and a pencil and trash can appear that allows you to edit/delete your message.

• Remove functionality from frontend
• Disallow on backend

Docker Container?

To replicate:

1. Create a channel
2. Select "general" channel
3. logout.

[method]getSecurityBanner invalid user error should briefly appear in upper right

After import, user should belong to 2 channels, and both should be favorited. The first channel is "general". The second channel is their "location".

Users added to existing location channels, do not have the location channel marked as a favorite.

Need to specify an Avatar when importing users from LDAP.

1. browser request is refused with ERR_CONNECTION_REFUSED when retrieving Avatar.
2. UI alignment looks weird. For example direct message right flex tab, username is offset to the right because UI expects an Avatar, but none is displayed

• Review differences from upstream merge
• See if it is worth the pain of merging
• Merge if required

When the application is started, and the user collection is getting created/populated, we are not setting the "status" field for each user. Consequently, it doesn't get set for a given user until that user logs in for the first time. This can cause some weird styling inconsistencies when viewing lists that include users that haven't logged in.

For example, in issue #15, since the list now shows all users instead of just online users, those that haven't logged in before are listed in black instead of the normal gray (for logged-out users). So it appears that they are there and available when they actually aren't.

When creating a direct message, if a security label is selected that causes a conflict with the chosen user, that user text is styled red. However, upon selecting that field and editing the target user, any label-related warnings are not updated until an option is selected in a drop-down list.

Steps to reproduce:

1. Log in as 'testuser1'
2. Create new direct message
3. In the 'with whom' dialog, enter 'testuser3'
4. Add any SCI/SAP label - the 'testuser3' entry should now turn red
5. Place the cursor in the 'with whom' field and start editing with the keyboard (e.g., hit backspace to remove the '3' from 'testuser3')
6. At this point, the remaining text for the target user is still red, and all other warnings still remain.

When labeling or relabeling a direct message or private group, potential/selected users are not getting highlighted when there is a security label conflict under 2 situations:

1. When typing in the auto-complete box to add a user, the entries in the drop-down list of users to select are never styled, even when some of those users do not have access to current labels.

2. In a private group, when a user is selected and their corresponding "chiclet" entry appears underneath the input box, that "chiclet" is never styled, even if security labels are selected that cause a conflict.

In both cases, the relevant security labels still get styled, and the pertinent warnings still get displayed as expected.

I believe this is a regression (pretty sure this was working earlier), and possibly caused by the change from displaying usernames to displaying full names. It is possible that the security label code is operating on usernames, while the drop-down/chiclet fields are only including full name data, and so they never match.

Acceptance Criteria:

• Add Custom message to user slide in box
• Add ability to assign a custom message
• Add ability to view a users custom message (user detail box)

This is a test issue.

**Update scope expanded to replace username with name through the application.

RocketChat displays the cryptic username instead of the user's name (full name) throughout the application. Need to replace everywhere.

When creating a channel/group, RocketChat searches using the username (e.g. bcleaver). However, it searches using the name (e.g. Theodore Cleaver) when adding a member to an existing channel/group (editing).

Acceptance criteria:

Channel:

• Create Channel "Add members" input should search by 'name'
• Create Channel added members should display 'name' field.
• Right tab (owner) - 'Add Users' input should search by 'name'
• Right tab (owner) - display 'name' of added members - can't fix depends on #41
• Right tab (owner) - display 'name' of existing members
• Right tab (owner) - display 'name' of existing member when viewing single user profile
• Right tab (non-owner) - 'Quick Search' input should search by 'name' field
• Right tab (non-owner) - display 'name' of existing members
• Right tab (non-owner) - display 'name' of existing member when viewing single user profile

Direct message:

• Create - "with whom" input should search by 'name'
• Create - display 'name' in "with whom" input
• Update - display 'name' in "with whom" input
• SideNav - display 'name' for existing direct messages

Private group:

• Create - "Members" input should search by 'name'
• Create - display 'name' of added members
• Update - display 'name' of existing members
• Update - "Members" input should search by 'name'
• Update - display 'name' of added members
• Right tab (owner) - 'Add Users' input should search by 'name'
• Right tab (owner) - display 'name' of added members - can't fix depends on #41
• Right tab (owner) - display 'name' of existing members
• Right tab (owner) - display 'name' of existing member when viewing single user profile
• Right tab (non-owner) - display 'name' of existing members
• Right tab (non-owner) - display 'name' of existing member when viewing single user profile

User Status:

• SideNav at the top - display 'name' of currently logged in user

Messages:

• Replace "Room_name_changed" system message
• Replace "User_added_by" system message
• Replace "User_removed_by" system message
• Replace "User_left" system message
• Replace "User_added" system message
• Replace "User_joined_channel" system message
• Replace "Welcome" system message
• Conversation - display 'name' of message sender

User typing:

• Bottom of room - display 'name' of member typing. Appears to other room members WHILE in the room.

Acceptance Criteria: Toast error instead of internal server error.

May be fixed in upstream.

It would be nice to see who is the creator/owner of the room in the member list.

When you add a user on a channel or group right-flex bar, it should show up immediately in the Member List below. Currently it only shows up when you hide and show the users.

To Replicate:

1. User 1 creates DM with user 2. Specify 'S' classification. DM should appear under direct messages section.
2. Click on created DM and verify 'S' classification.
3. User 1 creates DM with user 2. Specify 'U' classification. A new DM should NOT be created.
4. Click on the DM from step 1. Verify 'U' is now set.

RocketChat uses the members usernames for the room _id. Thus, we can never create a new DM when there's an existing DM. Worse yet, the create logic doesn't check for an existing room and calls upsert that updates an existing room. Thus, the old permissions are overwritten.

Acceptance Criteria:

• Default searches by name
• Add checkbox to return based on content of the message.