ixbrl-viewer multiple POST thinks its a document set

[michaelchadfleming]

What happened?

We're running into issues using the ixbrl-viewer for ESMA filings. We're using web server. When we run a package for company #1 using post we get correct results with a single correct output file that works correctly. However, when we run a second, different package, for company #2 we get incorrect output files. Two different html files are output. When we open the first file we get the following message:

"Displaying iXBRL document sets from local files is not supported. Please view the viewer files using a web server."

It appears to think it's a document set when the second post is sent. Is there a way to let the plug-in know that this is a different filing with a single instance and not a document set?

Below is what is being sent:

Austin Matherne emailed me about this and said, "I suspect this was caused by the changes in the ixbrl-viewer to add multi ixds support a little while back. Would you mind opening an issue in the for @paulwarren-wk to take a look at?"

Thanks as always, Chad

Version

Current master

With which browsers are you experiencing the bug?

Chrome

Documents

No response

Screenshots

While doing the investigation of the iXBRL viewer integration possibilities, an obstacle has been encountered. The current Arelle implementation leverages the usage of a web server to handle client requests. Upon exploring the potential ways of adding the new plugin to the existing infrastructure, it was noticed after making a second request using a different ESEF package obtained here https://filings.xbrl.org/ to the /validation endpoint, two HTML files are added to the output zip. One is the instance file of the for the company provided in the payload which is without an iXBRL viewer augmentation and the other one is with an iXBRL viewer augmentation, but an alert is shown when opening it and it does not seem to load. The first request provides the desired result - an HTML file enhanced with the iXBRL viewer capabilities.

Command and arguments used to launch the web server with the iXBRL viewer plugin in Arelle, the current latest viewer version is specified:

Results after pinging the /validation?media=zip endpoint with an ESEF package payload. The results are as expected:

One HTML file:

iXBRL viewer can be seen upon opening the HTML file:

Results after firing a second request to the same endpoint with a different ESEF package payload. In the output zip there are two HTML files, neither of which successfully present a fully loaded iXBRL viewer upon opening. This behavior is undesired:

Two HTML files in the output package:

HTML based on the package of the payload in the first request, viewer is added but does not load:

HTML based on the payload package in the second request, no enhancement with the iXBRL viewer is to be seen: Image

Taking such results into account, we are faced with an integration difficulty, since the current infrastructure of handling Arelle related requests is based on launching a configured web server.

[austinmatherne-wk]

Hi Chad,

Thanks for the additional details. I may have misunderstood your email. Is the filing in your second request a multi inline document filing, or is it combing the inline documents from both the first and second requests in the response of the second request?

[michaelchadfleming]

HI Austin,

Both input zips are single instance ESMA filings. I'll email over the zips because they're too big for GitHub's 25 MB restriction.

[michaelchadfleming]

Hi Austin, I wasn't able to share via email either. I attached files for the smaller, first filing. Here's a link to the larger filing: https://filings.xbrl.org/filing/969500FU4DRAEVJW7U54-2023-12-31-ESEF-FR-0

output_1.zip input_1.zip

[austinmatherne-wk]

Thanks, Chad. I'm able to replicate the issue. I suspect that the viewer overriding the keepOpen setting is responsible for the issue here.

@paulwarren-wk can you remind me why that's needed for multi-instance viewers?

[paulwarren-wk]

Thanks, Chad. I'm able to replicate the issue. I suspect that the viewer overriding the keepOpen setting is responsible for the issue here.

@paulwarren-wk can you remind me why that's needed for multi-instance viewers?

It's so that we can do the viewer creation all in one go at the end (on CntlrCmdLine.Filing.End), in order to avoid polluting the controller object with state from our plugin. I think you said that there was precedent for doing this in other plugins, so we should be able to switch to that approach and drop the use of keepOpen.

[austinmatherne-wk]

We specifically support it in ValidateXbrl for validation plugins. We can add something similar to the cntlr, but need to make sure it's cleaned up after the last plugin hooks run (the ValidateXbrl plugin data is cleaned up automatically after validation).

[paulwarren-wk]

That sounds like it should work. I think we would process each document in CntlrCmdLine.Xbrl.Run, and the write out the viewer and cleanup data in CntlrCmdLine.Filing.End.

[austinmatherne-wk]

I opened Arelle/Arelle/pull/1154. Once that's merged ixbrl-viewer should be able to implement and use it's own PluginData dataclass and drop the keepOpen argument.

[michaelchadfleming]

Thank you both for looking into this :)

[paulwarren-wk]

Hang on - we haven't actually done the work on the iXBRL viewer side yet.

We should re-open this issue, but I don't seem to have the permissions to do so.

[michaelchadfleming]

Sorry about that. I reopened the issue.

[michaelchadfleming]

@paulwarren-wk @austinmatherne-wk Hi Guys, I hope all is well :). I believe the last we spoke about this you were working on a fix and were close to fixing. Do you have any updates that I can share with our DFIN developers about planning and estimated timing of resolution? Thank you as always for your valuable time :), Chad

[michaelchadfleming]

@paulwarren-wk Thank you for fixing and merging to master :). We'll test soon and let you know if we encounter any issues. Thank you again for your valuable assistance and have a wonderful day :)