Cannot open attachment sent by agent in G Suite.

user4580579

Hello,

We are moving from Lotus Notes into G Suite.

When sending an analysis using agent, everything is OK in Lotus but Chrome browser and Android phones can not open attachments, because there is underscore after file extension (Analysis_name.pdf_).  When we open it through Internet Explorer it is (Analysis_name.pdf%20).

It happens on 11.1.1.7.171017 and 12.2.1.4.0 on IBM AIX.

Thanks,

Marcin

Edit: I forget about most important information. Problem occurs only when there is multibyte character in name of  analysis/attachment name.

Message was edited by: user4580579

user4580579

Here it is clearly visible, that there is a space at the end of the name:

--------------SASCH-Part-Level0

Content-Type: application/octet-stream

Content-Disposition: attachment; filename="Analysis Name ĄĘ.pdf "

Content-Transfer-Encoding: base64

Gianni Ceresa

Is that the real name of the analysis? "Analysis Name ĄĘ.pdf" ?

I guess I had the case some years ago where the issue happened with objects having special characters into their name, in your case the "ĄĘ" would be the special character.

Can you just try to have a simpler name without any special character and see if the same happen?

I'm pretty sure there was a MOS document on that somewhere, but as it was 4-5 years ago ... no idea where it is. Did you try searching in MOS?

Joel

There are numerous reported issues with Agents that have an analysis that contains special characters.

@Gianni Ceresa is probably referring to this -

Oracle Support Document 2353473.1 (OBIEE 12c: Export File Name May Not Be Correct If The Catalog Name Contains Special Characters on Chrome Browser) can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=2353473.1

There are a couple more on MOS relating to this issue.

user4580579

It's just a name created for tests but you're right that the issue only happens when there is special character into attachment name.

Our current workaround is to not use special characters.

I saw that note (2353473.1) but it only suggests workarounds that are not acceptable for us.

I hoped that note 'OBIEE : Email Subject Content With Russian Characters Does Not Display Correctly When Deliver Through Agents (Doc ID 2248051.1)' will give us a solution, there is even a patch included,  but it's not available for IBM AIX. So I'm looking further...

Greetings

Marcin

Gianni Ceresa

You can open a SR asking for a patch for AIX for the issue. As it's around for quite some time and you had the same issue on 12.2.1.4 which is the currently last version and totally supported they will maybe be able to do something more "acceptable" than renaming everything to remove special characters.

user4580579

Thank you for answer. I will open an SR.

Unfortunately, in production environment we are still on 11, we hope to move to 12 in two months but G Suite will be obligatory for everyone earlier. So i still need a solution for 11 that can be applied on server side.

user4580579

So, official solution from Oracle:

"You can use the outlook, Mozilla Thunderbird E SR 17.0.5 version and the problem is not getting reproduced with this mail client.

Problem doesn't get reproduced with zimbra client as well.

Please use the other email client where the problem won't come.

This is due to the mail client. So, we cannot support for this."

I agree that certain mail client can handle this. But I still have to find solution to open an attachment in browser.

Same problem occurs when we use special characters in Subject field of agent/mail. It's encoded to base64 and it ends up witch space in mail client.  This is part of eml of such mail:

From: OBIEE <obiee@xxxx.com.pl>

To: xxxxx@gmail.com

Subject: =?utf-8?B?VGVzdCDEmMSEAA==?=

Date: Thu, 18 Jul 2019 09:57:56 +0000

Content-Type: multipart/mixed;

  boundary="------------SASCH-Part-Level0"

Message-Id: <20190718095748.341EFD7E02B@gupfen.tzmo.com.pl>

This is a multi-part message in MIME format.

--------------SASCH-Part-Level0

Content-Type: text/plain; charset=utf-8

Content-Transfer-Encoding: quoted-printable

--------------SASCH-Part-Level0

Content-Type: application/octet-stream

Content-Disposition: attachment; filename="=?utf-8?B?QW5hbGl6YSDEhMSYLnhsc3gA?="

Content-Transfer-Encoding: base64

Gianni Ceresa

The answer is slightly disappointing (I'm not sure if Google is really not able to follow a standard in Gmail, and I bet there are standards defining how things are encoded, named, formatted).

I imagine you can still download the file from your browser and rename it to get rid of the space added to the extension.

It just isn't the same user experience you were hoping for ...