[MDS-6205] Permit condition specific reports #3302
Conversation
matbusby-fw
force-pushed
the
mds-6205-permit-reports
branch
from
0ca1062 to
dea99af
Compare
services/core-web/src/components/Forms/reports/ReportPermitRequirementForm.tsx
Outdated
Show resolved
Hide resolved
services/core-web/src/components/mine/Permit/PermitConditionLayer.tsx
Outdated
Show resolved
Hide resolved
services/core-web/src/components/mine/Permit/PermitConditions.tsx
Outdated
Show resolved
Hide resolved
|
I am still a bit unsure if what the condition requirement should be mapped to is the permit or the permit amendment (granted, the permit condition is already mapped to the permit amendment which is mapped to the permit but I get trying to avoid excessively complicated queries). But I also haven't tried running or rendering it. The decider to me would be "What happens when a permit has 2 amendments, and each of them have conditions with different report requirements?" <-- if it can handle that as is, then I'm happy. May just need to have dataMocks be a little more fleshed out with such a scenario. |
update PermitConditions.spec.tsx.snap update conditions to fix propogation issue update RenderRadioButtons.spec.js.snap Add report prop to permit condition form and disable button if report exists This commit introduces a new optional `report` prop to the `AddReportToPermitConditionForm` component, allowing it to use an existing report if available. Additionally, it modifies the permit condition layer to disable the "Add Report" button when a report already exists for the sub-condition, and ensures permits are refetched after adding a new report. Rename component and update references Renamed `AddRequestToPermitConditionForm` to `AddReportToPermitConditionForm` to better reflect its purpose. Also updated all references and added a default export for consistency. Added a snapshot test for the form component. Add report handling to permit conditions Enhanced permit conditions to include associated reports. Updated the UI to display report-related information and modified relevant constants, styles, and selectors accordingly. update interfaces to accomodate permit reports added permit condition specific report form updated action buttons on specific permit conditions and updated interface to expand and show action buttons when clicking into a condition. update backend to accomodate new permit condition specific details for mine reports migrate mine_report table with new permit specific details
… return to include these.
Renamed `AddReporttoPermitConditionForm` to `ReportPermitRequirementForm`. Updated the form to use new `mineReportPermitRequirement` structure. Enhanced `MineReportPermitRequirement` model with soft delete and additional fields like `initial_due_date` and `ministry_recipient`.
matbusby-fw
force-pushed
the
mds-6205-permit-reports
branch
from
460bd18 to
30e3f8f
Compare
It worked since it was just using it to grab the requirements for that permit, and since the important connection was between permit_condition and the requirement it would maintain the correct usage. That said, I think you're right that amendment is actually more appropriate, so I updated it to adhere to that. |
matbusby-fw
added
the
👍 Ready for review
services/core-api/app/api/mines/reports/models/mine_report_permit_requirement.py
Show resolved
Hide resolved
services/core-web/src/components/mine/Permit/PermitConditions.tsx
Outdated
Show resolved
Hide resolved
services/core-api/app/api/mines/reports/resources/mine_report_permit_requirement.py
Show resolved
Hide resolved
Added feature flag check to control permit condition editing. Updated PermitConditionLayer component to respect user permissions and feature availability. Simplified getMineReportPermitRequirements selector for clarity.
Removed `ValidationError` and `Raw` imports from `helpers.py` as they were not being used. Added a test case in `test_expected_auth.py` for `MineReportPermitRequirementResource` to ensure proper resource handling and permissions.
|
|
|
|
Objective
MDS-6205