Community
Participate
Working Groups
There is a regression - the deletion of attributes doesn't require confirmation. It's been performed immediatly. It's related to the bug #345725 - common reason
Created attachment 196769 [details] patch
Created attachment 196771 [details] patch v2
This is a bad defect, because nothing should be deleted without confirmation. No workaround. The fix was tested manually. All the existing JUnit tests are passing succesfully. The bug is result of a recent port of the editor to a newer Graphiti version. There was an API change in the Graphiti. A certain parameter was added to the method getUserDecision() of the DefaultDeleteFeature class. This way, the method is not being invoked (from the subclass ClickRemoveAttributeButtonFeature). Instead of it, another method from the super class is being invoked and it just returns true without confirmation. The fix is very small - i've just added a parameter to the invokation of getUserDecision() and the fix is in no conflict with other pending fixes, so the risk is very low.
Given that the Undo function doesn't seem to work in the editor (I believe there is an open bug for this), this problem is a bit worse than it might otherwise be. There is one possible workaround, which is to open the class in the Java editor and perform a series of Undo's there to return the class back to its original state, assuming the entity/class had not be saved already by the user. Given that the fix is extremely isolated and low risk and potentially involves data loss, I think I can support this fix going into RC3 (with a re-spin) or RC4. I will ask others from the PMC to provide feedback on whether re-spinning RC3 is an option for this bug. The change poses no risks to other components.
I'm glad Neil clarified that about 'undo' not working ... because "...because nothing should be deleted without confirmation." doesn't sound right. Things are deleted all the time without confirmation ... as long as undo is available. I'm ok with this fix, but see it as the "least of all evils" ... until undo is implemented.
(In reply to comment #5) > I'm ok with this fix, but see it as the "least of all evils" ... until undo is > implemented. David, I assume you prefer to respin RC3 for this fix, rather than wait for RC4?
> > David, I assume you prefer to respin RC3 for this fix, rather than wait for > RC4? I hadn't thought about that (one way or the other) ... but, if you want to change your green checkmark to a red x and ask for a respin, I'm fine with that ... as long as someone can confirm the build over the weekend (Monday is a Holiday in US).
+1 for re-spin of RC3 to pick this fix.
approve - respin sound like the best decision at this point
I will note that I asked Stefan if he could confirm the build this weekend, but given the late hour in his location he probably wasn't around to see it. He may be able to verify tomorrow, but I don't know that for sure. Given the low risk nature of this fix, I would be OK with putting this into RC4 although generally I would be in favor of getting a fix into the earliest possible build.
Ok, let's do it then (apply, respin for rc3) ... I'd like to get that releng fix in too ... and if Tran's not around, I'll be back around 8 or 10 tonight to do it (if he hasn't already). Much thanks.
Patch applied and released in RC3.
Verified in Build I-3.3.0RC4-20110603221533 Verified you receive a confirm delete dialog when you try to delete an attribute or entity from the diagram editor. See the link to view test steps for verification. http://wiki.eclipse.org/Dali_3.0_RC3
