# Aerial Measurements: Adjustment Source

**Goal**: Scope NAM adjustments to an `Estimate` or a `Project`.

Currently, NAM adjustments are scoped to the `Home` itself, which means that NAM adjustments are shared by estimates, projects and the home itself.

The business would like NAM adjustments to be scoped to the `Estimate` or `Project` creating them, allowing for the following use-cases:

1. Every new `Estimate`, starts up with a fresh NAM state, e.g. the otirinal report state we get from EagleView;
2. Creating a new `Estimate` from an existing estimate (copy feature) should also copy any NAM adjustment created on the source estimate, allowing users to build on that initial adjustment state without affecting the state of the source estimate;
3. `Project` when created, should inherit the NAM adjustments created in the estimate that originated the project, allowing users to make further NAM adjustments to the project, without affecting the source estimate;
4. When viewing an `Estimate`, the NAM area state is calculated dynamically by aggregating all adjustments created in the scope of that estimate and applying any rounding rules necessary;
5. When viewing a `Project`, the NAM area state is calculated dynamically by aggregating all adjustments created in the scope of that project and applying any rounding rules necessary;
6. When viewing a `Home`, the NAM area state is the original NAM area received by **EagleView**, ignoring any adjustment created by the system.

**Proposed Changes Note**

NAM adjustment records will only be created in the system after a proposed change is accepted, so no need to track proposed changes as adjustment sources.

## Data Model


## Questions for Kraig

1. Can a home have multiple active Siding projects where users would be making parallel NAM adjustments? yes (siding and roofing). We usually bypass the NAM for the second appt. This solution solves the bypass problem.
2. Will PII double check NAM measurements?
3. if we were to do either of the scenarios above how bad would it be if the change requests were out of sync with the database. this is in regards to a PII or a Project visit or possibly a rehash.
4. Would a feature toggle also cause out of sync data and how bad would that be?
5. RC training before rolling out? Sounds like a Yes.
6. Feature Toggle for releasing incrementaly but not expect to turn it off once the new system is live.
7. Launch plan: QA test period before turning it on in prod.

If we need to backfill existing data, we may only need to worry about projects in flight (Accepted, Finance Review, Good, Hold, Accounting Review, Closed Projects?).

## Notes

* Ping GLC about documentation around proposed changes.

where to add the table:

aerial measurements might be the best since we are adjusting them

need a new graphql query to grab data and migrate away from homes for roofing in aerial measurements

problem with adding roofing here will need to account for old roofing “System” / make it backwards compatible

looks at table if filtered version of sources can not find anything for Estimate then we can default to the old adjustments method which is inside of aerial measurements(dan smith disclaimer)

Grab Kraig to make sure we are not missing anything obvious.

multi steps

first step is to ship the table and model in aerial measurements component

* name for table: Adjustments
* can add a column for custom adjustments?
* feature toggle?

second is to find projects in a certain state to create aerial measurement adjustment records for existing projects.

* open questions( what do we need to backfill?) can we address this for both roofing and siding

third would be to update the consumers(graphql, controllers,) read off of aerial measurements adjustment records.

feature toggle can be added to switch back to the old method (on we dont write to column off we do)

dans better idea!

just create a new table for aerial measurement change requests

have to change more of nitro vs very specific sections we know about

PRO: can keep track of what we want. use it as a ledger