Formatting in All ticket list

mel

As part of testing the Builder and App Extension, I extended the Ticket form and replaced worklog_note_short with worklog_note in the Worklog list.

The full message is now displayed, which is what we wanted. However, the formatting (line breaks and spacing) is not preserved, making the content difficult to read. The content just goes from left to right and wraps to the next line and just keeps going. HTML Comments also gets mixed in. Our support team members are accustomed to seeing properly formatted messages with spacing and line returns in the current system.

The correct formatting is only visible after opening the individual Worklog record, which is expected behavior.

Is there a way to have worklog_note display with proper formatting directly in the Ticket Worklog list?

lsw-fabian

Hi @mel,

May I ask how you extended the ticket application? Did you build a new app and copy the ticket form into it?

Rich text is not meant to be displayed in lists; this simply doesn’t work with table formatting. Unfortunately, the behavior in lists cannot be changed.

I would generally never use worklog_note in lists, because the content can become very large due to images and formatting, and it does not scale well in larger systems (can cause long waiting times). worklog_note_short only includes a few hundred characters and removes all formatting so that it remains list‑friendly.

Instead, I can imagine two other options that could be implemented with a few hours of work from your (or our) side:

A dedicated 'All worklogs' button in the ticket form actions to display all mails or worklog entries in a single large rich‑text field. With additional functionality, you could also try to shorten long mail threads (although such features cannot always handle every mail formatting perfectly).
To navigate quickly through worklog entries, 'Previous' and 'Next' buttons in a worklog form action would also be possible. This would speed up navigation through individual worklog entries without showing one huge combined text field like in option 1. Additional options per agent could remove system generated messages or non-mail worklogs from this logic.

mel

"May I ask how you extended the ticket application?
I Created a new app that extends the ticket APP and all the necessary dependencies. Then I extended all the forms from the original Ticket APP from top to bottom in the menu structure to get to the form where I need all the customization work. I also had to review all the custom/extended forms permissions, stats, actions settings, back-end and front-end functions scripts and how they call each other, and replace and update things as required because the UI Id can potentially change in the extended forms. and review because the UI Id has changed. It was a lot of work to learn how the dependencies work together in the entire stack, but this is just my OCD kicking in. All my custom codes are surviving REI3 app updates so far because I did not touch or change/add anything from the original apps.

"I would generally never use worklog_note in lists,"
Me too, and I 100-1000% agree, but it was requested. Some techs have very specific needs, since we have a small team, so the the impact in percentage is high. The Techs wants the ability to traverse a list of tickets on the left side, and the right side, will show all the ticket worklogs (All of it) from newest to oldest based on the selected ticket on the left. Tech wants 1 click on the ticket itself, and no clicks to see all the work notes. If the tech had his way there be zero clicks in the entire platform. Jokes aside, this tells me he wants it like Microsoft Outlook style workflow like experience or similar to something like Zammad ticket navigation, which I checked it out on a .de demo site online. In a way, it is similar to a forum where you scroll and see all the updates/notes by just scrolling. I was able to simulate something like that in RAE, very close but the only thing not showing up properly is the work_log_note (full notes in the list)

If you see my screenshot, pretty much what I did with the extended Ticket App and all the extended sub forms.

lsw-fabian

Wow, that is a major redesign indeed! Awesome to hear that everything is still working. :-)
As I mentioned before, lists cannot display rich text formatting.

However, you could use a local variable on your ticket form with the rich text display option enabled and replace the list with that variable.

Create a new backend function to aggregate all the worklog information you need into a single text string (STRING_AGG() and CONCAT() will be your friends). You can also apply styling that suits your needs, as Tiny supports HTML and CSS. Use the ticket_id as an argument, make it executable by frontend functions, and set the return value to TEXT.

Lastly, create a new frontend function that runs before a ticket is opened to call your backend function. Use the return value to update the variable.

mel

Thank you for the suggestion. That makes sense. I came to acceptance that list cannot display rich text formatting =), would be cool though.

Still this platform blew Microsoft Access out of the water, only to have it fall back in and start drowning again. It is amazing the number of things that REI3 can do , all the things that the dev team thought of continues to surprise me. There are limitations as I am discovering on a day 2 day basis, but a highly capable platform. This is what I call a rapid app dev platform done right.

lsw-fabian

Thank you for your kind words.

We strive to make the platform better with every release and to create more value for both application authors and users. More features for list fields (even though so much is already possible today) are consistently on our roadmap.

I'm excited to see how your final ticket form turns out.