[NEW] adding custom sidebar icon method#459
Conversation
…s-engine into feat-adding-custom-sidebar-icon-method
|
My concern with SVG is we open ourselves to the common SVG attacks, unless there’s a way to get around this |
|
Hi @graywolf336, thank you for your comments, regarding the security issues, it is dealt with on the frontend by the below actions:
For a more detailed explanation of how the frontend deal with it, you can reach @ggazzo |
src/definition/rooms/IRoom.ts
Outdated
| customFields?: { [key: string]: any }; | ||
| parentRoom?: IRoom; | ||
| livechatData?: { [key: string]: any }; | ||
| source?: { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
src/server/accessors/RoomBuilder.ts
Outdated
| } | ||
|
|
||
| public setSidebarIcon(sidebarIcon: string): IRoomBuilder { | ||
| this.room.source.sidebarIcon = sidebarIcon; |
There was a problem hiding this comment.
source can be potentially undefined since it is optional according to the definition provided above.
There was a problem hiding this comment.
Since this property is not mandatory I decided to set it as an optional property
There was a problem hiding this comment.
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.
src/definition/package.json
Outdated
| { | ||
| "name": "@rocket.chat/apps-ts-definition", | ||
| "version": "1.28.0-alpha", | ||
| "version": "1.29.0-alpha.0", |
There was a problem hiding this comment.
Please revert this change. I know it is added automatically but it does not need to be committed by this PR.
src/definition/rooms/IRoom.ts
Outdated
| livechatData?: { [key: string]: any }; | ||
| source?: { | ||
| sidebarIcon?: string; | ||
| type: OmnichannelSourceType; |
There was a problem hiding this comment.
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
|
@graywolf336 I just commit some changes about your comments |
src/definition/rooms/IRoom.ts
Outdated
| customFields?: { [key: string]: any }; | ||
| parentRoom?: IRoom; | ||
| livechatData?: { [key: string]: any }; | ||
| sideBarIconSource?: { |
There was a problem hiding this comment.
Considering this is an omnichannel property, so can we add this ILivechatRoom instead of the base room object?
There was a problem hiding this comment.
From what I understand, this property should not be exposed actually.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
@ggazzo just created a PR with some modifcations on this PR #462 (review)
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
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. |
…ub.com/RocketChat/Rocket.Chat.Apps-engine into feat-adding-custom-sidebar-icon-method
|
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: |
|
This pull request introduces 1 alert when merging e698efe into 756bfff - view on LGTM.com new alerts:
|
murtaza98
left a comment
There was a problem hiding this comment.
Thanks @AllanPazRibeiro It looks good to me!! Really looking forward to the release of this one 🚀
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:
Why? 🤔
Links 🌎
PS 👀