gs.addInfoMessage in a BR on sys_attachment

[r_gissarl_]

Hi,

I have some Business Rules that I needed to create to perform management on attachements on knowledge base. Indeed, we just migrated from Eureka to Istanbul and the localization of the knowledge base is radiacally different.

So in a source KB, the BR deals with updates on the child KB even on attachements. This is where my prolem is : every update on the source KB show info the user on the updated child (via gs.addInfoMessage). But the gs.addInfoMessage never appears on the sys_attachement BR. Probably because it uses a different window (users use the manage attachements link). Is there a way to post an info to the user in this window (manage attachment) ? Or to force the addInfoMessage to appears on the current record ?

Thanks.

[Kalaiarasan Pus]

I would be interested to know this as well. I run into a similar problem sometime back and wasn't able to find a solution.

[Alexandre Sing2]

Hello,

I run into a similar problem, this time managing attachments on Service Portal :

Error or Info Message appear on back-office windows when I need them to appear on Service Portal.

When I reload my portal page, (a record producer), the message appears. (but it is way too late).

I have raised a HI ticket to ServiceNow support that failed to be resolved after three months.

I will raise a new ticket with this thread as a reference.

[oleksiykosenkov]

I ran into this problem and looking for a solution too. Please keep posting news, hope ServiceNow sorts it out.

[Alexandre Sing2]

Hello Community,

No good news, ServiceNow raised a problem : PRB1259875 but decided it was no "No-fix", because as they say :

"After carefully considering the severity and frequency of the issue, as well as the cost and risk of attempting a fix, a decision has been made not to address this issue in the near future. We do not make this decision lightly and we apologize for any inconvenience. The problem is marked as "won't fix" for now. If you consider that this issue has a major business impact for you please provide justification for us to work with our Development team to reevaluate the decision."

Our need was to inform end-users with info or error messages, when the attachments they were trying to upload were too heavy (sum of all attachments size) or of a prohibited file type.

Today our only possible workaround is to send email notifications based on an event, parameter-less event launched by the BR but it is not a suitable solution.

Edit : "If you consider that this issue has a major business impact for you please provide justification for us to work with our Development team to reevaluate the decision."

I provided a justification :

- Forbidden attachments extension handling is easier than Permitted attachments handling (in our case)

- Integrating ServiceNow with webservices that send tickets to a software that has different attachment handling features : in this case we have to be able to align Snow attachment handling to the target's one, and provide a correct UX.

Please provide yours also to convince ServiceNow.