changes for EDGAR 24.0.1 operation

[hermfischer-wf]

Reason for change

• Integrates iXBRLViewer to EDGAR workflow for release 24.0.1
  • EdgarRenderer must save twice, once for internal SEC use and second with redactions for public viewing
  • EDGAR must save stub as .xhtml for browers to successfully use xhtml-specific CSS inheritance
    • Stub file contains pre-publication filer data and/or confidential data to be redacted before publication - it must be encrypted by security plugin
  • Blocks saving of inline and supplemental documents, EdgarRenderer augments @ id as needed and may redact content as needed.
    • Augmented and redacted inline documents are saved by EdgarRenderer with EDGAR-specific encoding requirements (not saved by iXBRLViewer)
  • EdgarRenderer's GUI workflow provides its own LocalViewer with support of internal systems which require different URLs than the public website.
• Integrates security plugin for encrypted storage of non-public filer data.
• GUI operation supports EdgarRenderer output for both SEC and Arelle viewers (concurrently)

Description of change

• An application implementing plugin method iXBRLViewer.GenerateOnCall returning True blocks iXBRLViewer from the default workflow of generating on plugin method CntlrWinMain.Xbrl.Loaded or CntlrCmdLine.Filing.End. Instead iXBRLViewer implements plugin method iXBRLViewer.Generate which application invokes to generate according to its workflow.
  • E.g. EdgarRenderer
    1. returns True to iXBRLViewer.GenerateOnCall
    2. invokes iXBRLViewer.Generate providing override file name for stub file (with .xhtml suffix) and blocking output of any iXBRL or other documents, twice as needed for private and public redacted outputs in same workflow (in different directory paths with different stub file names).
    3. provides a security plugin to encrypt non-public filer data which may be in the stub file.
    4. provides its own LocalViewer for GUI operation, not using the LocalViewer of the default CntlrWinMain.Xbrl.Loaded operation.

Steps to Test

Run Arelle with edgar24.0.1-preview branches. Check for presence of stub .xhtml files.

review:
@Arelle/arelle
@paulwarren-wk

[aviary3-wk]

Security Insights

No security relevant content was detected by automated scans.

Action Items

• Review PR for security impact; comment "security review required" if needed or unsure
• Verify aviary.yaml coverage of security relevant code

---

Questions or Comments? Reach out on Slack: #support-infosec.

[austinmatherne-wk]

This seems problematic as another plugin essentially disables the ixbrl-viewer with this hook. The ixbrl-viewer tools menu and its settings no longer work as expected (Launch on Load, etc.) for users.

If I'm understanding correctly there's the need for 4 things.

1. for another plugin to generate a viewer on demand (with potentially its own customized/older javascript).
2. security hooks for another plugin to control how the viewer files are written to disk.
3. the option to only write the stub file to disk.
4. the ability to enable the ixbrl-viewer plugin, but only have it generate viewers on demand as requested by another plugin.

It seems reasonable that a user may want both the viewer that's generated by another plugin that depends on ixbrl-viewer (with whatever js it's using) along with the default ixbrl-viewer. In that case we need to handle requirement 4 through configuration and not universal control by another plugin.

The GUI can already be disabled by unselecting Launch on Load from the tools menu and I think we can update the CLI hook to exit if --save-viewer isn't used (saveViewerDest isn't set). Would that satisfy your requirements?

[hermfischer-wf]

EdgarRenderer has a browser menu with multiple options for the launched viewer, such as redline behavior, etc. I think in that configuration we don't want the regular plugin tools menu addition as well.

[austinmatherne-wk]

If you enable EdgarRenderer there's no longer anyway to get the latest Arelle viewer js? That will come as a surprise for users that enable both the EdgarRenderer and Arelle viewers (there are many).

If we go forward with this path (I don't think we should) we would need a notice in the GUI and CLI that enabling the EdgarRenderer overrides the Arelle viewer and if you want the latest and greatest Arelle viewer you must disable the EdgarRenderer.

[hermfischer-wf]

View  (menu ideas)
   EdgarRenderer
       Show Filing Data (launch ixviewer-plus)
       other options
   Arelle Viewer
       Show Filing Data (launch arelle viewer)
           Edgar 23.4 version (1.14.09)
           Edgar preview version (1.14.10)
           Latest public version (1.99.99)

[paulwarren-wk]

I think we can update the CLI hook to exit if --save-viewer isn't used (saveViewerDest isn't set).

I think that's already the case - if you don't specify --save-viewer it doesn't create a viewer (see
https://github.com/Arelle/ixbrl-viewer/blob/master/iXBRLViewerPlugin/__init__.py#L146)

EdgarRenderer has a browser menu with multiple options for the launched viewer, such as redline behavior, etc. I think in that configuration we don't want the regular plugin tools menu addition as well.

I wonder if we could separate the viewer into a common module and a plugin? The common module could then be used by both the standard CLI/GUI plugin, and the EDGAR plugin. The EDGAR code could use the viewer code without getting the standard viewer CLI and GUI menus. I don't know if there's an existing mechanism for plugin dependencies, but the common module could just be an ixbrl-viewer-common plugin that imports the code, but doesn't define any hooks.

[hermfischer-wf]

It would need to be dynamic, as some GUI users (and possibly cmd line workflows) interweave Edgar submissions with ESEF work, and wouldn't want to have a lot of clicks and the cmd line workflow may have to sequence through different disclosureSystems without reloading or reconfiguring.

[paulwarren-wk]

That's fine. If they want both EDGAR and standard iXBRL viewer functionality, they can load both plugins.