#2019 Request: Could you add "Chat" as Origin for User Requests?

[psn]

Hi,

Especially since Covid-19 we get a lot of requests for help coming in from Teams (in our setup).
It feels a bit "off" to have to choose phone or mail when that isn't really the case.

Would it be possible to add an Origin in User Requests that reflects this? For instance Chat or Messaging as a general catch-all for entered tickets that came in that way?
Reporting could make clear or at least visible that the emphasis is shifting from phone and mail to messaging when asking for support.

Thanks for providing iTop as open source and for considering the above suggestion.

kind regards,
peter

[Hipska]

You can adapt this yourself by creating a simple extension. If this would be considered by the Combodo team, then I would also suggest to add something like "orally".

[psn]

Hi Hipska,

Thanks for the reply. I am aware that we could implement this as an extension but it felt so ubiquitous that I thought it may be to iTop's advantage to have it in there from the start.
Also, when we get contacted by Teams it is more chat I refer to (could refer to any messaging software really), so not really orally, although that too would definitely be an origin that would make sense. :-)

best,
peter

[Jeffrey Bostoen]

I think it will depend a lot on the organization. For instance, we added "in person" and "monitoring" as origins.

As for chat, some organizations will be happy to keep it generic, others will really want to be more specific: WhatsApp, Twitter, Slack, Teams, Google, ... to get info on how their channels are used.

[Hipska]

"In person" is indeed a better definition..

[psn]

Hi Jeffrey,

That is definitely true. But my reasoning was that organisations mostly tend to use only one messaging/chat system so that reporting would make this visible.
It feels a bit strange that it isn't in there because you have phone, but not the specific phone system; you have mail but not the specific mail system. That makes sense to me and is why I would not include the specific messaging system per se. You also have monitoring, not the specific system you happen to use I suppose? (although that may make sense for your organisation, especially should you have multiple systems)

The point I'm trying to make (I think) is that there are a couple of origins in there as defaults, which makes sense, but some that are frequently used are missing, like monitoring, in-person and chat/messaging. As a bare minimum it feels like they should be in there for the people that use iTop out-of-the-box as it were. For bigger shops it is indeed not a big issue to write an extension and define their specific systems if they want to capture these in reporting also.

best,
peter

[Guillaume Lajarige]

Hello everybody,

Thanks for the suggestion, it's true that "chat" has become a standard way to interact with support now, so it would make sense to update the default values to reflect that.

But we have to consider that changing the default datamodel is never easy as it can break customizations made by the community and our customers if they already add this value. For now I see only 1 customer who has add "chat" among the origins so it should not be such a big deal and it will be put in the migration notes anyway.

I'll check with the product team next thursday and we will get back to you.

Cheers,
Guillaume

[Jeffrey Bostoen]

"Chat" does seem logical, but I also know some organizations who would want it way more specific.

Perhaps, if this is to be reviewed... I think a lot of custom origins will have been added already by various people. More breaking, but also more future proof: what if it becomes a typology?

Now, I'm also thinking about the case I already made about private/public case logs. Each entry could technically speaking have a different source, which might also lead to this kind of management info. Only: the original ticket wouldn't have this. So... if "origin" is ever introduced on a case log entry, should it be shared?

And further consideration is of course if any extensions really build up on the "origin" or if it's only stored as management info for now.

[Pierre Goiffon]

Hello,

Days are only 24h long, but I have in mind multiple evolutions for the caselogs. For example :

• Allow to "mark" certain important entries, or maybe certain phrases. This would ease caselog reading by keeping only the content that is important to understand the problem and its solving (get rid of the multiple messages to agree on a meeting date for example)
• Adding reactions to caselog entries, like in a chat app or in PR comments : an emoji you can add, that won't clutter the thread but nevertheless can be read by everyone

For such use cases indeed it would be nice to add to iTop caselog API the possibility to save specific data for each caselog entry. Each module can save something in there, and a specific callback could be called on caselog rendering so that the module can add what it needs.

I think this would also help in the uses cases you're pointong out Jeffrey ?

(sorry this is off-topic the original question, but I cannot help myself to jump in after Jeffrey's message :o) )

[Guillaume Lajarige]

Can we stay on the "origin" topic maybe? There are already several topics about the log evolutions 😁

EDIT: Saw the "off-topic" mention too late!

Guillaume

[Jeffrey Bostoen]

Definitely, I just mentioned the possibility of overlap between the two "origins" (defined in user request and perhaps per log entry) ;)

But to answer Pierre's question: I think it will quickly become much more of a mess if several callbacks have to be done for the logs.

[Guillaume Lajarige]

(Referenced internally under N°4703)

[Guillaume Lajarige]

Hello everyone,

This was accepted and will be included in iTop 3.1, both "chat" and "in_person" will be added. Thanks for the idea! ✌

Guillaume

[Timothée Callet]

Fixed in 3.1.0-beta released today