ContainerItemRenamer deletes objects when renames are not allowed
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Zope 3 |
Won't Fix
|
Undecided
|
Unassigned | ||
zope.copypastemove |
Fix Committed
|
Medium
|
Ilshad Khabibullin |
Bug Description
Reported by Christophe Combelles on <email address hidden>:
> I've experienced a dangerous behaviour with namechoosers :
>
> If the namechooser computes a name which is the same as the current name,
> the object is deleted!
>
> This is simple to reproduce :
> - register a name chooser that only returns "foobar"
> - create your object → ok it's name is foobar
> - from the Contents view of it's container, try to rename it (with a
> different name)
> - → deleted
>
> Someone should try to reproduce that, to be sure that's not a side effect
> of my app, but I don't think so.
Here's a unit test that reproduces the bug:
mg@pitonas:
Running tests at level 1
Running unit tests:
Running:
46/46 (100.0%) doctest_
Failure in test doctest_
Failed doctest test for zope.copypastem
File "/home/
-------
File "/home/
zope.copypastem
Failed example:
list(container)
Expected:
[u'foobar']
Got:
[]
Ran 46 tests with 1 failures and 0 errors in 0.081 seconds.
Changed in zope3: | |
status: | New → Won't Fix |
tags: | added: bugday20100424 |
Changed in zope.copypastemove: | |
assignee: | nobody → Ilshad Khabibullin (astoon) |
The patch applies cleanly to the zope.copypastemove trunk, but the test fails for reasons unrelated to the reported bug, as it depends on being able to import zope.app. container. sample, which is no longer a testing dependency. Likely we just need to write a dumb mock container inline in the test (which I would write as a unit test, but that is a de gustibus point).