search

agrc / porter

UGRC tracks the additions, replacements, and deletions of SGID items (in the broadest sense of add, replace, or delete) through issues in this repository.
https://gis.utah.gov/documentation/policy/
MIT License
2 stars 0 forks source link

Update data removal process #124

Closed steveoh closed 3 years ago

steveoh commented 3 years ago

Describe the problem you are having

We are unclear as an office on how to soft delete sgid data

The solution

  1. un-share the agol item and mark it as deprecated
  2. remove user privileges on the Internal SGID layer
  3. delete the Meta table row
  4. then after 2 weeks, delete the the agol item and delete the Internal layer.

Should a new checkbox be added

Yes more checkboxes will be added

steveoh commented 3 years ago

If I understand this correctly, the data removal process would then be something like

  1. mark the agol item as deprecated for some duration or while the replacement is being added.
    • we remove the sgid index item around this time.
  2. Then this new soft delete for 2 weeks.
  3. Finally the hard delete.
gregbunce commented 3 years ago

but, i think the replacement item should be fully in place (if there is one) before we do any of the above-mentioned stuff.

jacobdadams commented 3 years ago

So I think it would then become:

  1. mark the agol item as deprecated for some duration or while the replacement is being added.
  2. Once the replacement is up and running:
    • Unshare the AGOL item
    • remove the sgid index item
    • change the AGOL_ITEM_ID field to a non-GUID text like Removed from AGOL or Replaced by xyz from Uabc
  3. Finally the hard delete after two weeks of soft delete.
    • Delete the AGOL item
    • Delete the metatable row (?)
gregbunce commented 3 years ago

@jacobdadams also for step 2... "remove user privileges on Internal SGID layer" and then for step 3... "delete the Internal SGID layer" aye?

  1. mark the agol item as deprecated for some duration or while the replacement is being added.
  2. Once the replacement is up and running:
    • Unshare the AGOL item
    • Remove user privileges on Internal SGID layer
    • remove the sgid index item
    • change the AGOL_ITEM_ID field to a non-GUID text like Removed from AGOL or Replaced by xyz from Uabc
  3. Finally the hard delete after two weeks of soft delete.
    • Delete the AGOL item
    • delete the Internal SGID layer
    • Delete the metatable row (?)
steveoh commented 3 years ago

I think step 2d could be enter the agol item id and delete the row to propagate the delete to the open sgid. then 3c is unnecessary. If we need to rollback we can recreate the metatable row?

If that isn't nice, we can make changes to the open sgid cli tool.

I removed the term brownout as I think that implies that it will come back. Let's stick with soft delete or something other than brownout.

gregbunce commented 3 years ago

@jacobdadams what are your thoughts on steve's last suggestion? would that negatively affect any of your workflows?

jacobdadams commented 3 years ago

We would just need to make sure that Auditor runs at least once to pick up the 'deprected' flag in the metatable before we delete the row, or manually add {Deprecated} to the beginning of the AGOL title and mark it as deprecated.

gregbunce commented 3 years ago

of those two options, do you have a preference?

jacobdadams commented 3 years ago

I would fall on the side of leaving the metatable row in there as long as possible, but I don't feel super strong about it either way. Doing the deprecation stuff by hand introduces more opportunities for us to forget, while automation (when it works) does it every time.

gregbunce commented 3 years ago

how often does Auditor run?

jacobdadams commented 3 years ago

Every morning 5:00 AM

gregbunce commented 3 years ago

this issue was resolved in PR125 https://github.com/agrc/porter/pull/125