Data attribute inconsitency in trac.wiki.model.WikiPage while renaming a page

[Steffen Hoffmann]

When implementing an IWikiChangeListener for ​th:wiki:VotePlugin the initial draft didn't work as expected.

By comparing to known-good code for ​th:wiki:TagsPlugin I noticed, that there the new name is taken from page.name, while now I relied on the Resource object page.resource alone.

I feel that the current method WikiPage.rename is flawed since the initial commit in r9362 where it is updating only page.name but leaving page.resource unchanged. The WikiPage object passed to change listeners has both, the old and new name, and this is certainly unintended. However, it is easy to fix:

trac/wiki/model.py

@@ -189 +189 @@
             Attachment.reparent_all(self.env, 'wiki', old_name, 'wiki',
                                     new_name)
 
-        self.name = new_name
+        self.resource.id = self.name = new_name
         self.env.log.info('Renamed page %s to %s', old_name, new_name)
         
         for listener in WikiSystem(self.env).change_listeners:

I propose to fix it in stable and old-stable too.

[Steffen Hoffmann]

May I provide a test case too, or is it too trivial?

[Remy Blank]

Thanks for the patch. A test case would be nice, or if there's already a test case for WikiPage.rename(), add an assertion for the resource attribute there.

[Remy Blank]

We indeed do have a test case (test_rename_page), so you can just add an assertion after the one checking page.name.

[Christian Boos]

Good catch Steffen!

[Steffen Hoffmann]

add assertion to ensure correct page.resource.id after rename

[Steffen Hoffmann]

Replying to rblank:

We indeed do have a test case (test_rename_page), so you can just add an assertion after the one checking page.name.

Done here​.

Replying to cboos:

Good catch Steffen!

You're welcome. Piece of luck, improving both, a plugin and Trac core at once.

[Remy Blank]

Applied in [11735].