Skip to content
This repository was archived by the owner on Nov 5, 2025. It is now read-only.

Comments

[NEW] adding custom sidebar icon method#459

Merged
ggazzo merged 14 commits intoalphafrom
feat-adding-custom-sidebar-icon-method
Dec 20, 2021
Merged

[NEW] adding custom sidebar icon method#459
ggazzo merged 14 commits intoalphafrom
feat-adding-custom-sidebar-icon-method

Conversation

@AllanPazRibeiro
Copy link
Contributor

@AllanPazRibeiro AllanPazRibeiro commented Dec 9, 2021

What? ⛵

This PR is about a feature that allows the App Developer to send a custom icon (SVG) for the room's sidebar.

With that in mind, this PR adds the following stuff:

  • Method to set the icon name;
  • Add the room icon source type;

Why? 🤔

Links 🌎

PS 👀

@CLAassistant
Copy link

CLAassistant commented Dec 9, 2021

CLA assistant check
All committers have signed the CLA.

@AllanPazRibeiro AllanPazRibeiro changed the title Feat adding custom sidebar icon method [NEW] adding custom sidebar icon method Dec 9, 2021
@AllanPazRibeiro AllanPazRibeiro self-assigned this Dec 9, 2021
@graywolf336
Copy link
Contributor

My concern with SVG is we open ourselves to the common SVG attacks, unless there’s a way to get around this

@AllanPazRibeiro
Copy link
Contributor Author

Hi @graywolf336, thank you for your comments, regarding the security issues, it is dealt with on the frontend by the below actions:

  • All the potential injection attributes are removed.
  • And no inline script is executed.

For a more detailed explanation of how the frontend deal with it, you can reach @ggazzo

customFields?: { [key: string]: any };
parentRoom?: IRoom;
livechatData?: { [key: string]: any };
source?: {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This source property is so generic that someone who does not know Rocket.Chat's internals would not know what this is. In fact, I personally have no idea what it is referring to. What's the purpose of this? Can it be named something better and then mapped inside of Rocket.Chat?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that this name is too generic but I just decided to use the same property name as it used on the omnichannel room on Rocket.chat project as you can see on this PR

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I understand that. However, what I am saying is that we should map it to a name that actually provides meaning instead of further compounding the confusion and generics.

}

public setSidebarIcon(sidebarIcon: string): IRoomBuilder {
this.room.source.sidebarIcon = sidebarIcon;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

source can be potentially undefined since it is optional according to the definition provided above.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this property is not mandatory I decided to set it as an optional property

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, but what I am saying is that you're setting source.sidebarIcon and source could be undefined. Thus, you need to ensure that the object exists before you set a value on it.

{
"name": "@rocket.chat/apps-ts-definition",
"version": "1.28.0-alpha",
"version": "1.29.0-alpha.0",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please revert this change. I know it is added automatically but it does not need to be committed by this PR.

livechatData?: { [key: string]: any };
source?: {
sidebarIcon?: string;
type: OmnichannelSourceType;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to the PR on Rocket.Chat side, this value is not required and is not always provided either. https://github.com/RocketChat/Rocket.Chat/pull/23912/files#diff-9716852bd39e3ddd6e0db833e8f0b3f3eed21a1aebbb3201741dd90e67c48965R99

@AllanPazRibeiro
Copy link
Contributor Author

AllanPazRibeiro commented Dec 10, 2021

@graywolf336 I just commit some changes about your comments

customFields?: { [key: string]: any };
parentRoom?: IRoom;
livechatData?: { [key: string]: any };
sideBarIconSource?: {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering this is an omnichannel property, so can we add this ILivechatRoom instead of the base room object?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I understand, this property should not be exposed actually.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, the idea of that prop is to not be exposed so others can modify (we didn't enforce this), currently, the apps-engine sets the value on room creation based on apps info (but this happens only for omnichannel rooms) since that prop should not exists on other room types

@KevLehman

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ggazzo just created a PR with some modifcations on this PR #462 (review)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused with the implementation. It basically allows N number of channel icons (different for each room). That means an app would be able to set a different icon for every room it creates (which is a feature that can generate confusion to the end user as well)

From what I remember, an app would be able to use one icon and then all rooms created by the app would use that icon (if the app wanted it). Was this changed? 👀

(Additionally, will we limit the ability to set custom room icons to only omnichannel rooms? I know this is what we need right now, but, with PR 462, the code validations would need to be removed if apps engine wanted to allow this in the future)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't know if the same app can't have more than one integration, today we develop one by one, but it's up to the developer. The app will decide this when creating the room, this is a little less "plug and play", but at the same time more flexible, it involves less metadata and the behavior is also simpler. Today we are going to store the data in the room, otherwise we would need to store the information in the app, collect and evaluate this data, I don't think we have that prepared (I'm not an apps-engine expert, but I think it would take an infinite amount of work and a code more "coupled")

Today we are not interested in changing room icons to other types, we think this is a mess actually, but who knows, maybe in the future this 'source' field can live in all rooms not just omnichannel.

I'm a bit confused with the implementation. It basically allows N number of channel icons (different for each room). That means an app would be able to set a different icon for every room it creates (which is a feature that can generate confusion to the end user as well)

From what I remember, an app would be able to use one icon and then all rooms created by the app would use that icon (if the app wanted it). Was this changed? 👀

(Additionally, will we limit the ability to set custom room icons to only omnichannel rooms? I know this is what we need right now, but, with PR 462, the code validations would need to be removed if apps engine wanted to allow this in the future)

Copy link
Contributor

@murtaza98 murtaza98 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry a bit late to the review party here 😅

I had one piece of feedback. On all our omnichannel apps, we use this method to create an omnichannel room, so it would be awesome if we could add an extra param to this method to define the source of the channel when it is getting created... This way we don't have to make another call to DB to update the source post room creation

@felipetomm
Copy link

Sorry a bit late to the review party here sweat_smile

I had one piece of feedback. On all our omnichannel apps, we use this method to create an omnichannel room, so it would be awesome if we could add an extra param to this method to define the source of the channel when it is getting created... This way we don't have to make another call to DB to update the source post room creation

Wow!!! That's very awesome if you can add this info. Is an very important info to get metrics about customers channels, like others behaviors. At moment we identify channels by customFields of every Omnichannel Apps (and this is so rong)... A time ago i make an question about this here when Apps Source Type were implemented.
Thanks for note this @murtaza98 . We are looking forward to it :)

@AllanPazRibeiro
Copy link
Contributor Author

AllanPazRibeiro commented Dec 16, 2021

Folks,

I just committed a few modifications along with @ggazzo modifications to add the source as a parameter on LiveChat's create room method as @murtaza98 mentioned.

marking whose is in this thread:
@graywolf336 @ggazzo @felipetomm @murtaza98 @KevLehman @d-gubert

@lgtm-com
Copy link

lgtm-com bot commented Dec 16, 2021

This pull request introduces 1 alert when merging e698efe into 756bfff - view on LGTM.com

new alerts:

  • 1 for Unused variable, import, function or class

Copy link
Contributor

@murtaza98 murtaza98 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @AllanPazRibeiro It looks good to me!! Really looking forward to the release of this one 🚀

@ggazzo ggazzo merged commit 073efca into alpha Dec 20, 2021
@ggazzo ggazzo deleted the feat-adding-custom-sidebar-icon-method branch December 20, 2021 14:38
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants