UI: Cleanup Dialog to Manage Orphaned Data #117242

Harley Acheson · 2024-01-17T17:26:52+01:00

Harley Acheson commented

2024-01-17 17:26:52 +01:00

Creates a new "Cleanup" dialog that allows purging unused data blocks,
as well as a window used for managing unused data blocks.

Whether or not we keep, change, or improve our practice of removing unused data-blocks, we need tools that allow users to more easily select what to keep and delete.

The File/Cleanup menu confusingly contains six items that all call the same operator in different ways. They each remove unused data but there is one for local only, linked only, and one where you have to assume does both. And for all three there is an alternative that adds the word "Recursive" without much explanation. The tooltip description for all six is identical: "Clear all orphaned data-blocks without any users from the file". Even this text is confusing as "orphans" have no parents, while these are just without owner.

Once you decide which of the six items to select, you are then presented with an ugly confirmation dialog:

This patch replaces all six menu items with one item. And also adds a new item:

"Purge Unused Data..." gives you a single dialog where you can delete any type of unused data, in a manner that I think is more informative:

"Manage Unused Data..." brings up a window with Outliner in "Orphan Data" mode so that you can have more fine-grained control:

Unresolved Review Questions:

This is a recreation of a PR that is now closed, but can be found here.

Do not invoke modal UI items from an exec function. This code should be in the invoke callback.

Sorry about that. I swear I changed and tested that locally, but must have reverted or otherwise did something dumb that kept me from pushing that change. Now fixed.

Further more, any reasons not to use some operator-aware popup system, like WM_operator_props_dialog_popup or so?

Yes, that code does not offer the results and control I want here. I want a button to do the action, a button to cancel, and I want to show lists of items that would be cleared beforehand. This PR results in a dialog that matches the style of others in place and others that will be in place soon (#117153, #117152, #117151, #117154, #117155, #117156, #117157)

Another point I just realized: If you are renaming "orphan" to "unused", you should also tackle the other areas of the UI (starting with the name of the Outliner view itself).

We discussed this in the UI Module meeting and agreed this is not something to address here or yet.

Creates a new "Cleanup" dialog that allows purging unused data blocks, as well as a window used for managing unused data blocks. --- Whether or not we keep, change, or improve our practice of removing unused data-blocks, we need tools that allow users to more easily select what to keep and delete. The File/Cleanup menu confusingly contains six items that all call the same operator in different ways. They each remove unused data but there is one for local only, linked only, and one where you have to assume does both. And for all three there is an alternative that adds the word "Recursive" without much explanation. The tooltip description for all six is identical: "Clear all orphaned data-blocks without any users from the file". Even this text is confusing as "orphans" have no parents, while these are just without owner. Once you decide which of the six items to select, you are then presented with an ugly confirmation dialog: ![1PurgeNow.gif](/attachments/add118a5-50cc-431f-9a91-e6c853629139) This patch replaces all six menu items with one item. And also adds a new item: ![2image.png](/attachments/5d832bd3-7f32-4392-8789-dea8a8662034) "Purge Unused Data..." gives you a single dialog where you can delete any type of unused data, in a manner that I think is more informative: ![3image.png](/attachments/3973e631-eed2-4c1b-a0c3-3823dce781a4) "Manage Unused Data..." brings up a window with Outliner in "Orphan Data" mode so that you can have more fine-grained control: ![4ManageUnusedWindow.png](/attachments/406635b8-168e-49d9-a20e-6097f7522ba5) ### Unresolved Review Questions: This is a recreation of a PR that is now closed, but can be found [here](https://projects.blender.org/blender/blender/pulls/106653). > Do not invoke modal UI items from an exec function. This code should be in the invoke callback. Sorry about that. I swear I changed and tested that locally, but must have reverted or otherwise did something dumb that kept me from pushing that change. **Now fixed**. > Further more, any reasons not to use some operator-aware popup system, like WM_operator_props_dialog_popup or so? Yes, that code does not offer the results and control I want here. I want a button to do the action, a button to cancel, and I want to show lists of items that would be cleared beforehand. This PR results in a dialog that matches the style of others in place and others that will be in place soon (#117153, #117152, #117151, #117154, #117155, #117156, #117157) > Another point I just realized: If you are renaming "orphan" to "unused", you should also tackle the other areas of the UI (starting with the name of the Outliner view itself). We discussed this in the UI Module meeting and agreed this is not something to address here or yet.

3image.png

26 KiB

1PurgeNow.gif

160 KiB

2image.png

27 KiB

4ManageUnusedWindow.png

178 KiB

👍 2

Harley Acheson added 1 commit 2024-01-17 17:27:01 +01:00

5cbeb9f8c8 UI: Cleanup Dialog to Manage Orphaned Data

Creates a new "Cleanup" dialog that allows purging unused data blocks,
as well as a window used for managing unused data blocks.

Harley Acheson added this to the User Interface project 2024-01-17 17:27:31 +01:00

Harley Acheson requested review from Bastien Montagne 2024-01-17 17:27:39 +01:00

Julien Kaspar commented

2024-01-17 17:43:39 +01:00

It would be great to not have "Cancel" as the default action highlighted in blue.
While testing this PR today I kept noticing that I never actually purged any unused data :D

It would be great to not have "Cancel" as the default action highlighted in blue. While testing this PR today I kept noticing that I never actually purged any unused data :D

Harley Acheson added 1 commit 2024-01-17 17:50:36 +01:00

e823195e19 Change default button to Purge

Harley Acheson commented

2024-01-17 17:55:10 +01:00

@JulienKaspar - It would be great to not have "Cancel" as the default action highlighted in blue.

I updated this PR to set the Delete button as default. I don't like the chance of destructive behavior from an accidental press of Enter, but this is a very explicit operator selection and these things are unused and would be removed.

> @JulienKaspar - It would be great to not have "Cancel" as the default action highlighted in blue. I updated this PR to set the Delete button as default. I don't like the chance of destructive behavior from an accidental press of Enter, but this is a very explicit operator selection and these things are unused and would be removed.

Harley Acheson added 2 commits 2024-01-17 18:59:39 +01:00

662b8b6569 Merge branch 'main' of projects.blender.org:blender/blender into ManageData2

0ee4253e8e Use Invoke rather than Exec

Harley Acheson commented

2024-01-17 19:14:21 +01:00

@mont29

Sorry about that. Until Julian pointed it out I didn't realize that I had not changed from exec to invoke, as you correctly pointed out in review. I swear I did make that change locally and tested it, but must have reverted or did some other dumb thing that kept that change from being pushed. Now fixed.

@mont29 Sorry about that. Until Julian pointed it out I didn't realize that I had not changed from exec to invoke, as you correctly pointed out in review. I swear I did make that change locally and tested it, but must have reverted or did some other dumb thing that kept that change from being pushed. Now fixed.

👍 1

Jonas Holzman commented

2024-01-17 23:23:52 +01:00

On a small stylistic note, we might not want to capitalize all of the dialog's title words here. The "From This File" part is additional information compared to "Purge Unused Data" which is the original operator name, and should thus probably be emphasized to add contrast. This would thus give us "Purge Unused Data from this file".

Harley Acheson commented

2024-01-18 00:29:07 +01:00

On a small stylistic note, we might not want to capitalize all of the dialog's title words here. The "From This File" part is additional information compared to "Purge Unused Data" which is the original operator name, and should thus probably be emphasized to add contrast. This would thus give us "Purge Unused Data from this file".

Maybe. But there is an advantage of Title Case in that it is easily described and (fairly) unambiguous. As in we could just tell people to use title case for the title and sentence case for the body and that would work in most cases. Otherwise we can get weird holy wars where one person changes all the titles slightly then someone else changes them back. LOL

> On a small stylistic note, we might not want to capitalize all of the dialog's title words here. The "From This File" part is additional information compared to "Purge Unused Data" which is the original operator name, and should thus probably be emphasized to add contrast. This would thus give us "Purge Unused Data from this file". Maybe. But there is an advantage of Title Case in that it is easily described and (fairly) unambiguous. As in we could just tell people to use title case for the title and sentence case for the body and that would work in most cases. Otherwise we can get weird holy wars where one person changes all the titles slightly then someone else changes them back. LOL

thorn-neverwake commented

2024-01-18 04:14:43 +01:00

First-time contributor

The "From This File" part is additional information compared to "Purge Unused Data" which is the original operator name

Grammatically, that's neither sentence case, nor title case. The fact that "Purge Unused Data" is the actual name of the operator seems incidental; what something is called in the code base shouldn't be the overall determining factor on if the menu item presents well.

The actual correct use of title case would be: Purge Unused Data from this File

But, I think Harley's point on potential grammatical holy wars is a fair one, so initial caps might be preferred. (As in the example, Purge Unused Data From This File)

>The "From This File" part is additional information compared to "Purge Unused Data" which is the original operator name Grammatically, that's neither sentence case, nor title case. The fact that "Purge Unused Data" is the actual name of the operator seems incidental; what something is called in the code base shouldn't be the overall determining factor on if the menu item presents well. The actual correct use of title case would be: _Purge Unused Data from this File_ But, I think Harley's point on potential grammatical holy wars is a fair one, so initial caps might be preferred. (As in the example, _Purge Unused Data From This File_)

Harley Acheson commented

2024-01-18 05:26:43 +01:00

The actual correct use of title case would be: Purge Unused Data from this File

I'm not seeing that variation in any style guide...

AMA: Purge Unused Data From This File
AP: Purge Unused Data From This File
APA: Purge Unused Data From This File
Bluebook: Purge Unused Data from This File
Chigago: Purge Unused Data from This File
MLA: Purge Unused Data from This File
NY Times" Purge Unused Data From This File

> The actual correct use of title case would be: _Purge Unused Data from this File_ I'm not seeing that variation in any style guide... AMA: Purge Unused Data From This File AP: Purge Unused Data From This File APA: Purge Unused Data From This File Bluebook: Purge Unused Data from This File Chigago: Purge Unused Data from This File MLA: Purge Unused Data from This File NY Times" Purge Unused Data From This File

thorn-neverwake commented

2024-01-18 05:49:08 +01:00

First-time contributor

I'm not seeing that variation in any style guide...

The war has begun... ;)

Yeah, it's seriously going to be a stylistic thing. I have issues with AP style, and a fun thing with AMA - sometimes they even contradict themselves in odd ways. (I enjoyed a long battle of "healthcare" vs "health care" last year, that was fun...)

So, i think your original approach - just full initial caps - will be a good catch-all.

> I'm not seeing that variation in any style guide... The war has begun... ;) Yeah, it's seriously going to be a stylistic thing. I have issues with AP style, and a fun thing with AMA - sometimes they even contradict themselves in odd ways. (I enjoyed a long battle of "healthcare" vs "health care" last year, that was fun...) So, i think your original approach - just full initial caps - will be a good catch-all.

Bastien Montagne referenced this pull request

2024-01-18 21:28:54 +01:00

IDManagement: Update the Purge operator to display an interactive popup. #117304

Bastien Montagne commented

2024-01-18 22:28:52 +01:00

I'll split my input in several comments, to avoid a single monster post.

This feedback will be on a technical (code and architecture) level only.

The usability/UI/UX review has already been done and validated by the UI module. For what's worth, from an end-user perspective, I find the proposed changes in this PR to be a great improvement over current situation.

I'll split my input in several comments, to avoid a single monster post. This feedback will be on a technical (code and architecture) level only. The usability/UI/UX review has already been done and validated by the UI module. For what's worth, from an end-user perspective, I find the proposed changes in this PR to be a great improvement over current situation.

Bastien Montagne commented

2024-01-18 22:29:19 +01:00

Here is some feedback on a fairly high, general level.

Further more, any reasons not to use some operator-aware popup system, like WM_operator_props_dialog_popup or so?

Yes, that code does not offer the results and control I want here. I want a button to do the action, a button to cancel and I want to show lists of items that would be cleared beforehand. This PR results in a dialog that matches the style of others in place and others that will be in place soon (#117153, #117152, #117151, #117154, #117155, #117156, #117157)

I don't think this is the right approach. If the results of a high-level API does not give satisfaction, then this API should be improved. The solution of going into lower level of code should only be considered in two cases:

For rapid prototyping and feature/UI/UX design level review. A proper solution should then be implemented before the technical implementation review begins.
In case the cost of modifying the existing API would be extremely high for the expected returns.

I am fairly certain we are not in situation 2. here. Situation 1. was OK to get the feature validated on a usability level, but it is now in a 'technical review before merging' state.

Here are the Pros I see to using/improving generic API vs. hacking specific solutions using low-level code:

Consistency: A similar behavior is ensured for all usecases. If some changes or improvements are needed, all existing use-cases benefit from it (and/or checking on the impact of the proposed changes on existing use cases can uncover unexpected side effects or issues).
Simplicity and Safety: Using an API already used in several other places avoids having to consider complex, maybe hidden aspects of the code.
Maintainability and Upgradeabilty: If fixes or improvements are needed, they can be done in a single place (implementation of the API), instead of having to chase down all potentially similar cases in custom code implementing (roughly) the same thing.

On a practical level, I think the only missing thing from WM_operator_props_dialog_popup is the dual Cancel/Validation buttons, with customizable labels? Currently, this API will generate a single 'validation' button, and cancel is done by clicking outside of the popup or hitting escape.

I believe that adding an explicit cancel button for all these operator-based pop-ups would be beneficial (easier for users who are not familiar with Blender UI history) and consistent with other types of popups. This is a separate design & PR topic for the UI module though.

Here is some feedback on a fairly high, general level. > > Further more, any reasons not to use some operator-aware popup system, like `WM_operator_props_dialog_popup` or so? > > Yes, that code does not offer the results and control I want here. I want a button to do the action, a button to cancel and I want to show lists of items that would be cleared beforehand. This PR results in a dialog that matches the style of others in place and others that will be in place soon (#117153, #117152, #117151, #117154, #117155, #117156, #117157) I don't think this is the right approach. If the results of a high-level API does not give satisfaction, then this API should be improved. The solution of going into lower level of code should only be considered in two cases: 1. For rapid prototyping and feature/UI/UX design level review. A proper solution should then be implemented _before_ the technical implementation review begins. 2. In case the cost of modifying the existing API would be extremely high for the expected returns. I am fairly certain we are not in situation 2. here. Situation 1. was OK to get the feature validated on a usability level, but it is now in a 'technical review before merging' state. Here are the Pros I see to using/improving generic API vs. hacking specific solutions using low-level code: * Consistency: A similar behavior is ensured for all usecases. If some changes or improvements are needed, all existing use-cases benefit from it (and/or checking on the impact of the proposed changes on existing use cases can uncover unexpected side effects or issues). * Simplicity and Safety: Using an API already used in several other places avoids having to consider complex, maybe hidden aspects of the code. * Maintainability and Upgradeabilty: If fixes or improvements are needed, they can be done in a single place (implementation of the API), instead of having to chase down all potentially similar cases in custom code implementing (roughly) the same thing. ---- On a practical level, I think the only missing thing from `WM_operator_props_dialog_popup` is the dual Cancel/Validation buttons, with customizable labels? Currently, this API will generate a single 'validation' button, and cancel is done by clicking outside of the popup or hitting escape. I believe that adding an explicit cancel button for all these operator-based pop-ups would be beneficial (easier for users who are not familiar with Blender UI history) and consistent with other types of popups. This is a separate design & PR topic for the UI module though.

Bastien Montagne commented

2024-01-18 22:30:44 +01:00

Here is a summary of the high-level technical issues I have with the current code. I will ignore smaller issues for the time being.

From initial review of the old PR:

Adding a new operator (OUTLINER_OT_orphans_cleanup), which is essentially an empty shell only used to trigger the creation of the pop-up.
Using low-level pop-up creation code (UI_popup_block_invoke), with a custom UIButton callback (wm_block_orphans_purge), that essentially duplicates the same code in existing operator's exec function (outliner_orphans_purge_exec).

Re-using and improving the existing operator (OUTLINER_OT_orphans_purge) and using operator-popup API instead should be possible.

New issues identified while working again on that PR:

The undo stack is broken in current PR (it seems to create a new undo step everytime the user updates an operator setting, and no undo step for the actual deletion operation).
This is a direct consequence of trying to by-pass the whole operator system and using 'raw' code like wm_block_orphans_purge.
The reported amount of IDs to be deleted is not always correct.
The main reason is that there are inter-dependencies between the operator settings, e.g. local and recursive settings will affect the results for the linked data, etc.
The reported amount of IDs to be deleted does not update when settings change.
This is also easily addressed when using the existing WM Operator/PopUp framework.

Issues identified while reviewing this PR, but which already exist with current main code:

Current implementation will leave behind 'dirty' tagging of IDs in case the operator is cancelled (addressed as part of the work done in !117304).
Undoing of purge operation works well, but when re-doing it (ctrl-Z), linked purged data is not deleted anymore, reported to keep track of it: #117303.

For reference, I created a similar PR (!117304) using/modifying the existing operator (OUTLINER_OT_orphans_purge), and the high-level WM_operator_props_dialog_popup API to show it. As a bonus, it also updates the numbers of to-be-deleted IDs when the user updates the settings.

Also, here is a simple test blendfile: linked_data_purge.blend. To get one directly unused local collection, and several indirectly unused IDs, both local and linked:

Unlink the local collection for the scene.
Clear the 'fake user' status of the unlinked collection in the Outliner.

Here is a summary of the high-level technical issues I have with the current code. I will ignore smaller issues for the time being. ***From initial review of the old PR:*** * Adding a new operator (`OUTLINER_OT_orphans_cleanup`), which is essentially an empty shell only used to trigger the creation of the pop-up. * Using low-level pop-up creation code (`UI_popup_block_invoke`), with a custom UIButton callback (`wm_block_orphans_purge`), that essentially duplicates the same code in existing operator's `exec` function (`outliner_orphans_purge_exec`). Re-using and improving the existing operator (`OUTLINER_OT_orphans_purge`) and using operator-popup API instead should be possible. ***New issues identified while working again on that PR:*** * The undo stack is broken in current PR (it seems to create a new undo step everytime the user updates an operator setting, and no undo step for the actual deletion operation). _This is a direct consequence of trying to by-pass the whole operator system and using 'raw' code like `wm_block_orphans_purge`._ * The reported amount of IDs to be deleted is not always correct. _The main reason is that there are inter-dependencies between the operator settings, e.g. `local` and `recursive` settings will affect the results for the `linked` data, etc._ * The reported amount of IDs to be deleted does not update when settings change. _This is also easily addressed when using the existing WM Operator/PopUp framework._ ***Issues identified while reviewing this PR, but which already exist with current `main` code:*** * Current implementation will leave behind 'dirty' tagging of IDs in case the operator is cancelled (addressed as part of the work done in !117304). * Undoing of purge operation works well, but when re-doing it (ctrl-Z), linked purged data is not deleted anymore, reported to keep track of it: #117303. ----- For reference, I created a similar PR (!117304) using/modifying the existing operator (`OUTLINER_OT_orphans_purge`), and the high-level `WM_operator_props_dialog_popup` API to show it. As a bonus, it also updates the numbers of to-be-deleted IDs when the user updates the settings. ![image](/attachments/fd4cba00-44a0-4264-b970-93f5d070ee69) Also, here is a simple test blendfile: [linked_data_purge.blend](/attachments/356e52ff-95f1-40ec-aa2a-2df86ebab214). To get one directly unused local collection, and several indirectly unused IDs, both local and linked: * Unlink the local collection for the scene. * Clear the 'fake user' status of the unlinked collection in the Outliner.

Bastien Montagne commented

2024-01-18 22:31:20 +01:00

Another point I just realized: If you are renaming "orphan" to "unused", you should also tackle the other areas of the UI (starting with the name of the Outliner view itself).

We discussed this in the UI Module meeting and agreed this is not something to address here or yet.

Fair enough. I disagree with this decision (in fact, if the renaming from 'Orphaned' to 'Unused' is agreed on, I would rather have the name change done in existing Blender UI before landing this patch, as a cleanup step, through another PR). But if the UI module is happy with having two different names for the same thing in the UI, so be it.

> > Another point I just realized: If you are renaming "orphan" to "unused", you should also tackle the other areas of the UI (starting with the name of the Outliner view itself). > > We discussed this in the UI Module meeting and agreed this is not something to address here or yet. Fair enough. I disagree with this decision (in fact, if the renaming from 'Orphaned' to 'Unused' is agreed on, I would rather have the name change done in existing Blender UI before landing this patch, as a cleanup step, through another PR). But if the UI module is happy with having two different names for the same thing in the UI, so be it.

Brecht Van Lommel referenced this pull request

2024-01-19 15:53:10 +01:00

IDManagement: Update the Purge operator to display an interactive popup. #117304

Bastien Montagne referenced this pull request

2024-01-19 16:58:36 +01:00

IDManagement: Update the Purge operator to display an interactive popup. #117304

Brecht Van Lommel commented

2024-01-19 17:55:48 +01:00

So, i think your original approach - just full initial caps - will be a good catch-all.

The convention in Blender is MLA, so we should just follow that.
https://developer.blender.org/docs/features/interface/human_interface_guidelines/writing_style/#ui-labels

> So, i think your original approach - just full initial caps - will be a good catch-all. The convention in Blender is MLA, so we should just follow that. https://developer.blender.org/docs/features/interface/human_interface_guidelines/writing_style/#ui-labels

Brecht Van Lommel commented

2024-01-19 18:05:27 +01:00

On a practical level, I think the only missing thing from WM_operator_props_dialog_popup is the dual Cancel/Validation buttons, with customizable labels? Currently, this API will generate a single 'validation' button, and cancel is done by clicking outside of the popup or hitting escape.

I believe that adding an explicit cancel button for all these operator-based pop-ups would be beneficial (easier for users who are not familiar with Blender UI history) and consistent with other types of popups. This is a separate design & PR topic for the UI module though.

Perhaps the most straightforward way of getting this to work would be to change the new wm_block_confirm_create to call ot->ui between the message and the buttons, so that these new confirmation popups support showing operator properties.

> On a practical level, I think the only missing thing from WM_operator_props_dialog_popup is the dual Cancel/Validation buttons, with customizable labels? Currently, this API will generate a single 'validation' button, and cancel is done by clicking outside of the popup or hitting escape. > > I believe that adding an explicit cancel button for all these operator-based pop-ups would be beneficial (easier for users who are not familiar with Blender UI history) and consistent with other types of popups. This is a separate design & PR topic for the UI module though. Perhaps the most straightforward way of getting this to work would be to change the new `wm_block_confirm_create` to call `ot->ui` between the message and the buttons, so that these new confirmation popups support showing operator properties.

Harley Acheson commented

2024-01-19 18:35:08 +01:00

The current plan is that I will address a few different issues with this PR as described by Bastien:

Its invoke function should then popup the UI, and return CANCELLED (such that no undo step is stored for just showing the popup).
The popup data OrphansPurgeData should not store the operator itself. It could store the operator type (though this is not critical).
The 'Delete' button should then be an 'operator' button calling the 'exec' callback, and setting again the operator properties from the values stored in the OrphansPurgeData.
Not sure how to deal with the updates of the popup UI (needed when modifying options changes the amount of deleted IDs) in that case...

So get this into a shape where it could be accepted as is. However, I'd leave this as "WIP" while investigating integration with, and/or improvements to the generic WM operator popup code. Or, as mentioned by Brecht, integration of these into the new confirm code. It would be nice if all these things were a bit more consistent.

I had always planned on looking at improving the operator dialogs like the operator confirms, but thought the confirms were an easier "sell" to do first since they are so visible. My itch for improving this "Orphan cleanup" will be sated a bit when the new confirms are approved.

The current plan is that I will address a few different issues with this PR as described by Bastien: * Its invoke function should then popup the UI, and return CANCELLED (such that no undo step is stored for just showing the popup). * The popup data OrphansPurgeData should not store the operator itself. It could store the operator type (though this is not critical). * The 'Delete' button should then be an 'operator' button calling the 'exec' callback, and setting again the operator properties from the values stored in the OrphansPurgeData. * Not sure how to deal with the updates of the popup UI (needed when modifying options changes the amount of deleted IDs) in that case... So get this into a shape where it _could_ be accepted as is. However, I'd leave this as "WIP" while investigating integration with, and/or improvements to the generic WM operator popup code. Or, as mentioned by Brecht, integration of these into the new confirm code. It would be nice if all these things were a bit more consistent. I had always planned on looking at improving the operator dialogs like the operator confirms, but thought the confirms were an easier "sell" to do first since they are so visible. My itch for improving this "Orphan cleanup" will be sated a bit when the new confirms are approved.

Harley Acheson referenced this pull request

2024-01-24 21:54:34 +01:00

Consolidation of Operator Dialogs #117489

Bastien Montagne referenced this pull request

2024-01-25 10:20:39 +01:00

Consolidation of Operator Dialogs #117489

Bastien Montagne referenced this pull request

2024-02-06 18:31:01 +01:00

IDManagement: Update the Purge operator to display an interactive popup. #117304

Bastien Montagne referenced this pull request

2024-02-06 18:32:49 +01:00

IDManagement: Update the Purge operator to display an interactive popup. #117304

Harley Acheson referenced this pull request

2024-02-06 20:33:33 +01:00

IDManagement: Update the Purge operator to display an interactive popup. #117304

Bastien Montagne referenced this issue from a commit

2024-02-09 17:01:42 +01:00

IDManagement: Update the Purge operator to display an interactive popup.

Bastien Montagne commented

2024-02-12 10:35:44 +01:00

@Harley think this one should be closed now, and a new PR created for the 'Managed Unused Data' new operator?

Bastien Montagne requested changes 2024-02-12 10:41:05 +01:00

Bastien Montagne left a comment

needs to be updated or closed and re-created

Harley Acheson commented

2024-02-12 18:32:34 +01:00

Closing. This functionality was added by Bastien using a better method - a Props Dialog - here: #117304

Will propose a separate PR for the "Managed Unused Data" portion of this.

Closing. This functionality was added by Bastien using a better method - a Props Dialog - here: #117304 Will propose a separate PR for the "Managed Unused Data" portion of this.

Harley Acheson closed this pull request

2024-02-12 18:32:37 +01:00

Harley Acheson referenced this pull request

2024-02-18 19:16:29 +01:00

UI: Manage Unused Data Operator #118435