- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-08-2022 08:37 PM
When glide.ui.journal.use_html is set to true, agents can paste images into Additional Comments and Work Notes. The trouble is, when the comment is posted, the activity shows an entry for image uploaded which is customer visible. Any way to stop this and just leave the image in the work note/comment ? The email configuration table has an option for this for emails (don't attach to record, just leave in email)... wondering if there is something similar for the journal
Edit for clarity:
Steps to reproduce:
1) Set glide.ui.journal.use_html to true
2) Go to an incident in agent workspace. Paste an image into the work notes rich text editor. Post the work note
3) The work note will post into the activity with the image embedded.
4) The image is also uploaded as an attachment (twice actually) to the incident. If you go to the attachments table, there are three attachments associated with this procedure.
- the attachment on the sys_journal_field table
- two attachments on the incident table (as ZZYY). These are the attachments that are visible to the customer.
My question is, is it possible to not have these last two attachments (YYZZincident) upload into the incident record?
The email client configuration table (sys_email_client_configuration) has a setting for attachments (attachment_send_action) where you can specify that attachments should not be uploaded to the original record and just remain in the email. I'm wondering if there is something similar for sys_journal_field. Thanks.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-09-2022 05:58 AM
Support has informed me that this has been fixed in the Tokyo release.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-01-2023 10:38 AM - edited 03-01-2023 10:40 AM
Hello,
If you don't mind, perhaps you can add your own information such as what you've tested and seen as there are reports this is still occurring, even in Tokyo. Did you verify this on your side or just relay what support told you? Additionally, it'd be nice to see the PRB number associated to this so that we can verify? Would be helpful the community to know that before marking a response as correct and closing this thread out.
Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-08-2023 01:23 AM
Hi Allen,
We have been facing this issue since our upgrade to Rome, and it is still present after our upgrade to Tokyo.
The problem associated with it is PRB1554068 and the KB article is KB1117340.
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1117340