Open timkinnane opened 6 years ago
Rocket.Cat should be nameable as it is not a "branding-friendly" name.
FYI changing the username from rocket.cat
to something else does not change the username on message sent by a Livechat Trigger...
The avatar goes to /avatar/rocket.cat
instead of the changed username.
I can create a separate issue if needed, but thought I'd mention this since others may reference this issue for info on rocket.cat
.
Create a redirect from /avatar/rocket.cat
to /avatar/new.username
. I use Cloudflare and made a redirect in about a minute.
There are some issues with the way notifications are handled in Rocket.Chat that cause confusion for both developers and users.
Below I’ve outlined each concern, but I’d like comment and direction from @RocketChat/core team, to find a comprehensive solution and give clarity to these features moving forward.
Thanks to @graywolf336 for writing up the first section on Rocket.Cat…
Who or What Is Rocket.Cat?!
Ah the age old question for current developers and the confusing question for new developers interacting with Rocket.Chat. Rocket.Cat currently exists in the code base of Rocket.Chat as a user that is always there. The reason this happens is that throughout the code base of Rocket.Chat we have always needed a user to exist for various reasons, whether that any or all of the following:
Message_ErasureType
is set toUnlink
and all messages of the deleted user are thus assigned to Rocket.Cat * For messages coming over via the SlackBridgeHowever, there has been mass confusion over this for developers of all kind, and especially users, who don't have the time to investigate what exactly the Rocket.Cat user is. For example, a user might think that the Rocket.Cat user belongs to the Internal Hubot and expect that when they disable the Internal Hubot the messages from the Rocket.Cat user will go away. Yet that's not the case and thus is very confusing to have disabled the Internal Hubot but still get messages from the Rocket.Cat user when you try to send a message in a channel you're muted in.
So, I think we need a distinction in docs (possibly assisted by semantic helper methods) as to where and why Rocket.Cat should be used. Which I think should be only as the fallback default “system” user:
Stream notifications VS alerts
There’s currently four different visual feedback components in the UI.
There is no obvious hierarchy for developers to know how to use these tools and make contributions that don’t just further complicate the experience for users.
They are all visually different and do not communicate any sense of differing priority in the notifications - for lack a better term, it all just feels kinda random.
I think at least one of these approaches should be dropped. I would prefer it was the stream notifications...
Why use stream notifications?
Currently, the approach of creating stream notifications as pseudo messages is adding to the confusion.
Bot notifications
Custom instance specific apps and bots might need to send notifications too.
They should be distinct from the system notifications, they could even just be a normal message with some special formatting. Any solution to the general issues should consider how a
bot
and asystem
notification are different, in code and design.Mobile...
I have no idea how these issues relate across the mobile apps?
This discussion can close related issues (#3869, #4016, #4103) to keep all in one place.
Pinging for comment @engelgabriel @Sing-Li @rodrigok @graywolf336 @karlprieb @rafaelks