Report Editing

• All totals, savings numbers, HES scores, measures tables, CAZ tables, etc.

• Which pages exist at all for a given program (e.g., CAZ only when combustion is enabled).

• Titles and boilerplate strings like CAZTitle, ComfortTitle, DefinitionsAFUE, etc.

• Editable in the report editor (hand‑edits)
  

  • Page titles / section headings (e.g., CAZ title, comfort/safety headings).

  • Some “notes” blocks and explanatory text.

  • Captions under photos.

  • Paragraph text and bullet lists.

  • Structure that you can change in the UI:
    • Page ordering (drag & drop pages / hide pages).
    • Whether certain optional pages/sections are shown.
    • Selection of which photos are used on a page (via the image picker).

• The current report HTML (including any text edits, hide/show states, and inline changes).

• It does not recalc the underlying energy/audit data; it just saves the edited report rendering for this project.

• The current page ordering and any editor‑specific metadata that’s part of the payload.

• Section ordering.

• It still expects dynamic slots (numbers, measure rows, CAZ tables, etc.) to be re‑filled from each project’s own data at build time; you don’t hard‑code those numbers into the template.

• Edited boilerplate text (titles, explanations, footers) you changed in the editor.

• Which pages are shown/hidden by default.

• Rebuild report (from current audit data, no template change)
  
  • What gets refreshed:
  • • All dynamic fields from the audit / calculator: savings, costs, measures, CAZ numbers, tables, etc.
    • Anything controlled by reportdata only (e.g., which measures exist or changed).
  • What may be preserved:
    • Depending on editor behavior, some textual hand‑edits might be lost if they live in dynamic areas, but the structural state that’s stored in your last “Save” (page ordering, hidden/visible toggles) is usually preserved if the rebuild logic merges back into your saved artifact.
  • Mental model: “Re‑run the engine and refill the numbers into my current layout.”
• Rebuild from template (switching or re‑applying a saved report template)
  
  • What gets applied from the template:
  • • Page ordering and which pages exist in that template.
    • Default section visibility and boilerplate text from that template.
  • What gets applied from the current project:
    • All dynamic numeric/tabular content.
    • Project‑specific photos and notes.
  • What happens if you then change pages and hand‑edits and click “Save” again:
    • Those changes are saved back to your project’s artifact file, not to the template.
    • If you later “Rebuild from template” again, you’ll override your project’s layout with the template’s saved ordering and boilerplate, then re‑fill the dynamic data.

• Where order comes from initially
  
  • The Zeus model has a base pageorder (see getphotodictionary loops over $zeusmodel->pageorder).
  • That plus program logic determines which pages are available and their default order for a project.
• How it changes in the report editor
  
  • When you drag pages, hide pages, or re‑order sections, the editor’s code builds an updated page ordering list that’s included in the “Save” payload to savereportdata.
  • That ordering is then stored in the project’s report artifact file.
• Interaction with templates:
  
  • Template with saved ordering:
    • When you “Rebuild from template”, the template’s saved page ordering becomes the new baseline for that project.
  • You then change order and save hand‑edits:
    • The project’s artifact now contains your new order; subsequent simple “Rebuild report” should generally respect that ordering (because it rebuilds dynamic material into your saved layout, not into the raw template) unless a code path explicitly discards layout state.
  • If you again explicitly “Rebuild from template”:
    • Template ordering wins again, overwriting the project’s custom ordering and text for any sections that template controls, then the audit data is refilled.

• Q: What content is dynamically filled from audit data?
  A: Anything computed or stored as part of the audit: measures, costs, savings, CAZ results, health & safety notes, definitions text, etc.
• Q: What can be edited in the report editor?
  A: Text in edit-me regions (titles, paragraphs, bullets, captions), visibility of pages/sections, page ordering, and photo selection/placement via the image picker.
• Q: What is saved when I choose “Save”?
  A: A project‑specific artifact file containing your current report HTML + layout + metadata (page order, hidden/visible flags, captions, hand‑edited text). It does not alter the underlying audit data or template project.
• Q: What is saved when I choose “Save as template”?
  A: A template‑project artifact that captures your current layout, page ordering, visibility, and boilerplate edits as the default for future projects using that template, while still expecting dynamic numeric content to come from each project’s audit data.
• Q: What is reloaded when I “Rebuild from template”?
  A: The saved template’s layout (including its ordering and defaults) plus freshly generated dynamic reportdata for the current project. Any previous per‑project layout overrides are replaced by the template’s versions at that moment.
• Q: Specifically, how does page ordering work if I use a template with saved ordering, then change it and save hand edits?
  A:
  
  • Using the template sets the project’s ordering to the template’s order.
  • Your subsequent edits and “Save” calls store a new ordering on the project.
  • Plain “Rebuild report” generally respects that project ordering while refreshing numbers.
  • A later explicit “Rebuild from template” will again reset ordering (and other layout defaults) back to the template’s saved version, then refill dynamic data.

• If rebuilding with a template, the template order is preserved first. So the sidebars/pages order will appear first in template order.
• Then it will append sidebars/pages from the new project you reran the template on.
• For example, assuming the template didn't have a spillover page for Attic. That new attic spillover page will be inserted below the main Attic page.
• If a sidebar/page exists in the new report but not in the template. It looks at the order of the template and attempts to place that sidebar/page wherever it should have been placed.
• If it can't find where it should be placed, it's appended to the end of the sidebar/pages

• Template photos will be overwritten by the new project photos.
• If you have a cover photo in the template and a cover photo in the new report. The new report photo takes precedence over the template photo. So the new report photo will be shown instead.
• If a photo exists in the template but not the new report, then the template photo will be used instead.

Pages that should be grouped stay together.

If a page has a "Notes: XYZ" associated with it, it's a group and will move together.

For example, the "Walls" page & "Notes: Walls" page will stay together when dragging/moving either one.

The main page (Walls) will always be on top, and the "Notes" page will always be below it.

You cannot move a page between another grouped page section.

Let's say my sidebar looks like this:

• Walls
• Notes: Walls
• Attic
• Notes: Attic

If I tried to move Walls between Attic & Notes: Attic BOTH Walls & Notes: Walls will be moved above it (staying in the same place)

If I wanted to move the Walls group below the Attic group, I must drag either the Walls OR Notes: Walls sidebar below the Notes: Attic sidebar, and BOTH Walls & Notes: Walls will be placed below Notes: Attic

Let's say I wanted to move the Attic group above the walls group.

If I moved the Attic OR Notes: Attic between the Walls & Notes: Walls. The Attic group will be placed above the Walls sidebar

The same applies for non-grouped pages. If I tried to move the Greenhouse Gas Footprint sidebar between Attic & Notes: Attic, Greenhouse Gas Footprint will be placed above Attic.

Besides that, all the sidebars should be draggable/movable to wherever you want to place them.