[dcansys]

Summary

Adds beta, items-only JSON import through import_from_json on both Service and serverless ADR. Supports text, HTML, tables, trees, images, animations, scenes, and files, with shared validation, document and item tags, relative media-path handling, and configurable per-item failure collection.

Adds a versioned JSON Schema generated from the importer’s field specifications, a canonical sample, end-user documentation, and an example. Report templates remain outside this import path and continue to use the existing load_templates* APIs.

Testing

• uv run pytest tests/json_import -q -p no:cacheprovider
• make smoketest
• make check

Fixes https://ado.internal.synopsys.com/tfs/ANSYS_Development/Portfolio/_workitems/edit/1464631

[Copilot]

Pull request overview

Adds a JSON import path for serverless ADR report items, backed by shared Pydantic schemas for validating item payloads.

Changes:

• Adds shared JSON schema models for report items and top-level import payloads.
• Adds a serverless importer that loads JSON, creates a default layout template, and saves text/table/image/file/scene/tree items.
• Adds normalization helpers for JSON-style tags and table/tree conversion.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

File	Description
src/ansys/dynamicreporting/core/utils/json_importer_models.py	Defines Pydantic models for supported JSON report item payloads.
src/ansys/dynamicreporting/core/serverless/json_importer.py	Implements serverless import logic for validated JSON report items.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 94.24307% with 27 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.64%. Comparing base (c4ed862) to head (e56078a).

Files with missing lines	Patch %	Lines
...micreporting/core/utils/json_item_import/parser.py	89.83%	7 Missing and 5 partials ⚠️
...ynamicreporting/core/utils/report_remote_server.py	92.00%	2 Missing and 2 partials ⚠️
src/ansys/dynamicreporting/core/adr_service.py	70.00%	2 Missing and 1 partial ⚠️
src/ansys/dynamicreporting/core/serverless/adr.py	88.46%	2 Missing and 1 partial ⚠️
...micreporting/core/utils/json_item_import/schema.py	94.33%	1 Missing and 2 partials ⚠️
...namicreporting/core/utils/json_item_import/spec.py	98.03%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #548      +/-   ##
==========================================
+ Coverage   82.08%   82.64%   +0.56%     
==========================================
  Files          32       39       +7     
  Lines        9443     9904     +461     
  Branches     1698     1774      +76     
==========================================
+ Hits         7751     8185     +434     
- Misses       1195     1210      +15     
- Partials      497      509      +12     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 9 comments.

[viseshrp]

@dcansys this PR goes in the opposite direction of what we agreed in our meeting. We agreed to adopt Pydantic for the subset of models this import needs, as the first step towards replacing the hand-built service and serverless models. Instead, 06b41b2 removed Pydantic entirely and added a third set of hand-built models and validation code, about 1,500 lines. Did you review this code yourself before pushing it? Which AI model did you use to write it?

[viseshrp]

@dcansys this PR goes in the opposite direction of what we agreed in our meeting. We agreed to adopt Pydantic for the subset of models this import needs, as the first step towards replacing the hand-built service and serverless models. Instead, 06b41b2 removed Pydantic entirely and added a third set of hand-built models and validation code, about 1,500 lines. Did you review this code yourself before pushing it? Which AI model did you use to write it?

@margalva Please correct me if I am wrong about the direction of this PR.

[margalva]

@dcansys this PR goes in the opposite direction of what we agreed in our meeting. We agreed to adopt Pydantic for the subset of models this import needs, as the first step towards replacing the hand-built service and serverless models. Instead, 06b41b2 removed Pydantic entirely and added a third set of hand-built models and validation code, about 1,500 lines. Did you review this code yourself before pushing it? Which AI model did you use to write it?

@margalva Please correct me if I am wrong about the direction of this PR.

@viseshrp @dcansys from my notes on the backlog refinement, I have: remove pydantic. We will add a data validation in the core of ADR at a later time, not specific to this functionality. We will most probably use pydantic to do that, but it needs to be in the core of ADR.

[viseshrp]

@dcansys this PR goes in the opposite direction of what we agreed in our meeting. We agreed to adopt Pydantic for the subset of models this import needs, as the first step towards replacing the hand-built service and serverless models. Instead, 06b41b2 removed Pydantic entirely and added a third set of hand-built models and validation code, about 1,500 lines. Did you review this code yourself before pushing it? Which AI model did you use to write it?

@margalva Please correct me if I am wrong about the direction of this PR.

@viseshrp @dcansys from my notes on the backlog refinement, I have: remove pydantic. We will add a data validation in the core of ADR at a later time, not specific to this functionality. We will most probably use pydantic to do that, but it needs to be in the core of ADR.

@margalva Hmm, do you have a date for the notes? I remember what you have mentioned is what we decided before we put this on hold until Dragan was back from vacation in July/August and then had a meeting again where we decided to either adopt Pydantic or extend the current set of models to include JSON import without rebuilding something from scratch, based on the time we had to deliver this feature. I also remember we put the original PR on hold because the original code proposed to write a complete set of new models from scratch, similar to the current state of this PR. Sorry, but I'm confused.

[viseshrp]

@dcansys this PR goes in the opposite direction of what we agreed in our meeting. We agreed to adopt Pydantic for the subset of models this import needs, as the first step towards replacing the hand-built service and serverless models. Instead, 06b41b2 removed Pydantic entirely and added a third set of hand-built models and validation code, about 1,500 lines. Did you review this code yourself before pushing it? Which AI model did you use to write it?

@margalva Please correct me if I am wrong about the direction of this PR.

@viseshrp @dcansys from my notes on the backlog refinement, I have: remove pydantic. We will add a data validation in the core of ADR at a later time, not specific to this functionality. We will most probably use pydantic to do that, but it needs to be in the core of ADR.

@margalva Hmm, do you have a date for the notes? I remember what you have mentioned is what we decided before we put this on hold until Dragan was back from vacation in July/August and then had a meeting again where we decided to either adopt Pydantic or extend the current set of models to include JSON import without rebuilding something from scratch, based on the time we had to deliver this feature. I also remember we put the original PR on hold because the original code proposed to write a complete set of new models from scratch, similar to the current state of this PR. Sorry, but I'm confused.

@margalva @dcansys
I found this in our meeting notes:

So, we decided to switch to pydantic later, but use the existing models for now. That is still not addressed in this PR. We are back to square one. The only difference here from the original implementation is that we have removed pydantic completely and replaced it with our own version of pydantic-like models and validation instead of reusing what we already have in our code (a 3rd model/solution path -- same problem as the very first attempt and also typical of mistakes made by AI).

[dcansys]

@dcansys this PR goes in the opposite direction of what we agreed in our meeting. We agreed to adopt Pydantic for the subset of models this import needs, as the first step towards replacing the hand-built service and serverless models. Instead, 06b41b2 removed Pydantic entirely and added a third set of hand-built models and validation code, about 1,500 lines. Did you review this code yourself before pushing it? Which AI model did you use to write it?

@margalva Please correct me if I am wrong about the direction of this PR.

@viseshrp @dcansys from my notes on the backlog refinement, I have: remove pydantic. We will add a data validation in the core of ADR at a later time, not specific to this functionality. We will most probably use pydantic to do that, but it needs to be in the core of ADR.

@margalva Hmm, do you have a date for the notes? I remember what you have mentioned is what we decided before we put this on hold until Dragan was back from vacation in July/August and then had a meeting again where we decided to either adopt Pydantic or extend the current set of models to include JSON import without rebuilding something from scratch, based on the time we had to deliver this feature. I also remember we put the original PR on hold because the original code proposed to write a complete set of new models from scratch, similar to the current state of this PR. Sorry, but I'm confused.

@margalva @dcansys I found this in our meeting notes:

So, we decided to switch to pydantic later, but use the existing models for now. That is still not addressed in this PR. We are back to square one. The only difference here from the original implementation is that we have removed pydantic completely and replaced it with our own version of pydantic-like models and validation instead of reusing what we already have in our code (a 3rd model/solution path -- same problem as the very first attempt and also typical of mistakes made by AI).

Hi @margalva @viseshrp, below is my recollection of how the requirements and implementation direction for JSON report-item import evolved. Please correct me if I’ve missed anything.

• Initial request: Patrick from Fluids One requested a way for ADR Serverless to import report items via JSON format, including items whose associated files may be in different locations. He recommended Pydantic for validation, noting that Fluids One and other teams across the organization use it.

• PoC: We found no dedicated JSON report-item import in the existing implementation. After discussing the approach with Marina, we built a proof of concept using Pydantic. The requirements, initial JSON schema, demo, and next steps were presented at team demo.

  Why Pydantic: we saw Pydantic as a good fit because it follows established validation practices and would align us with other teams. Since JSON item import is a new feature, idea was to introduce it there as a contained first use—without changing existing logic—so we could deliver the feature, gain experience with the library, and gather feedback before considering wider adoption (introducing this would create some overlap with existing validation, but trade-off was to leave final decision upon the team).

  PoC/demo: [import-json-items-poc]

• First PR: With no concerns raised at the demo, implementation proceeded. The first PR introduced the feature as new code, using the PoC project as its starting point. Feedback on the PR raised concerns about the new code.

• First refinement: Then we met and agreed to use Pydantic as the primary import and validation mechanism, replacing the existing validation approaches rather than adding more code. We planned to do the refactoring after my summer vacation. Meanwhile, agent-generated implementation plans were added to the PR, proposing a broader unified-exchange approach.

The agent-generated MVP plan said to be "additive only" and to "not modify the existing models."

• Second refinement: After my vacation, we reviewed the plans and discussed the updated direction. The scope had shifted toward unified exchange import/export.
• Latest refinement: After another round of PR refactoring based on the second refinement, we held another refinement and now it was purposed/agreed to completely remove Pydantic—including its json import item code, remove export, and implement JSON report-item import using the existing mechanisms.

[dcansys]

@viseshrp @margalva:

I agree the parser duplicates some item validation, and I'll remove the checks the backend validators already cover, such as tree value types.

I don't think the JSON item import can be built on the existing models alone, though. They validate ADR item content, not the import document. The JSON contract needs conversion before those models can accept it: tables are transposed, missing tree keys and values are filled in, relative media paths are resolved, and tags are converted to strings. There's also no existing model for the document fields such as schema_version and app_id. The two backends also validate differently, and their validators run per item during creation, so a later invalid item could leave a partial import.

The importer already creates every item through the existing APIs, so the existing validators still run. My proposal is to keep only the JSON-specific checks and conversion, remove the duplicated item checks, and delegate item validation to the backends.

To me the take-away is: fewer importer checks give less duplication but weaker guarantees about the JSON contract.

---

When asked an agent to analyze the main branch and what's needed for integration based on new JSON schema:

"What the existing validators won't enforce:
The current schema includes rules that the existing validators don't enforce. For each one, the team needs to decide whether to keep a small check or relax the schema:

Rejecting unsupported schema_version major versions. This needs a few lines.
Checking that xaxis and yaxis name existing columns.
Checking that every table row has the same length as columns.
Rejecting or warning about unknown keys, including strict_keys.
Reporting every problem in the document at once, before anything is saved. Without that, an invalid later item can leave a partial import.
Making both backends accept the same documents. They currently validate trees and HTML differently."

[viseshrp]

@dcansys Go ahead and make your changes. Please use Opus 5.5 for review and fixing as per my comments. Let me know when done. I will do my review after.

[dcansys]

Please read: CODE_REVIEW_WALKTHROUGH.md before review.