Skip to content

Add Confirmation Before Dev Tool Removal and Modification [AARD-2033] #1265

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 10 commits into
base: dev
Choose a base branch
from

Conversation

ryanzhangofficial
Copy link
Member

@ryanzhangofficial ryanzhangofficial commented Aug 8, 2025

Task

Add a confirmation dialog when removing a Dev Tools–placed scoring zone, allowing the user to either remove it temporarily (current behavior) or permanently by also deleting it from the Dev Tools cache.

Jira Ticket

Symptom

Currently if you remove a protected zone or scoring zone from the configure field panel that is placed by the dev tool it will remove it until the next refresh. Only the dev tool is able to cache scoring zone placement.

Solution

Popup a confirmation window when we remove a scoring zone that was placed by dev tools, and give us the option of removing it from dev tools as well (saving to cache).

Verification

  • Tested temporary removal + refresh
  • Tested permanent removal + refresh
Screenshot 2025-08-08 102909

Before merging, ensure the following criteria are met:

  • All acceptance criteria outlined in the ticket are met.
  • Necessary test cases have been added and updated.
  • A feature toggle or safe disable path has been added (if applicable).
  • User-facing polish:
    • Ask: "Is this ready-looking?"
  • Cross-linking between Jira and GitHub:
    • PR links to the relevant Jira issue.
    • Jira ticket has a comment referencing this PR.

@ryanzhangofficial ryanzhangofficial self-assigned this Aug 8, 2025
@ryanzhangofficial ryanzhangofficial added the ui/ux Relating to user interface, or in general, user experience label Aug 8, 2025
@ryanzhangofficial ryanzhangofficial marked this pull request as ready for review August 8, 2025 17:26
@ryanzhangofficial ryanzhangofficial requested review from a team as code owners August 8, 2025 17:26
Copy link
Member

@rutmanz rutmanz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be better to say that the zones were defined in the field file/asset file/mirabuf file and avoid all reference to the developer tools. I think that, in theory, the developer tools are used by us to add this information to the cached files that people download, and so we shouldn't expect that they've used them / know they're there.

Also, this doesn't handle modifying the zones

@ryanzhangofficial ryanzhangofficial marked this pull request as draft August 12, 2025 18:33
@ryanzhangofficial ryanzhangofficial changed the title Add Confirmation Before Dev Tool Removal [AARD-2033] Add Confirmation Before Dev Tool Removal and Modification [AARD-2033] Aug 13, 2025
@ryanzhangofficial ryanzhangofficial marked this pull request as ready for review August 14, 2025 20:42
@ryanzhangofficial ryanzhangofficial force-pushed the ryan/2033/add-confirmation-before-dev-tool-removal branch from 6f24ff1 to 988f39a Compare August 14, 2025 20:44
}

return (
<Dialog open={isOpen} onClose={onClose} maxWidth="sm" fullWidth>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine to make language consistent rather than doing this ternary stuff. Removing a zone is a modification or change to the field, and I think it makes the code a lot cleaner to use the same words

<strong>Temporary {actionType === "modification" ? "modification" : "removal"}:</strong>{" "}
{actionType === "modification"
? "Save changes until next field reload. Original zone will reappear when you refresh or reload the field."
: "Remove zone until next field reload. The zone will reappear when you refresh or reload the field."}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"refresh or reload the field" is kind of a weird expression, "refresh the page" is much clearer IMO

<Typography variant="body2">
<strong>Permanent {actionType === "modification" ? "modification" : "removal"}:</strong>{" "}
{actionType === "modification"
? "Save changes to the field file cache. This will persist your modifications on future loads."
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Save changes to the local asset file. This will persist your modifications until you remove it from the cache."

actionType?: "removal" | "modification"
}

const DevtoolZoneRemovalModal: React.FC<DevtoolZoneRemovalModalProps> = ({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should probably be renamed if this is being generalized


const editor = new FieldMiraEditor(parts)

if (zoneType === "scoring") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it makes very much sense to have all of this in this conditional, it looks like you can generalize this for either zone type and avoid making unnecessarily specific code

devZone.name === originalZone.name &&
devZone.alliance === originalZone.alliance &&
devZone.parentNode === originalZone.parentNode &&
JSON.stringify(devZone.deltaTransformation) === JSON.stringify(originalZone.deltaTransformation)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it appears you're using these properties because they overlap on the two different zone preferences types. I think it would make sense to enforce this more rigorously by having a BaseZonePreferences type with the common properties that they both extend. This would be basically the same as ScoringZonePreferences|ProtectedZonePreferences, except that it would be robust aginst changes to those types

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, generating IDs on load for the zone preferences objects (they don't need to persist in the cache or across reloads) might be a more robust way to compare two zones that doesn't require the structuredclone

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ui/ux Relating to user interface, or in general, user experience
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants