RE: [xwiki-users] $xwiki.copyDocument, objects, and cache

This message revisits a problem I had about a month ago. Time pressure prevented my investigating this further, but I now believe I have a firm handle on the problem, as well as more information and a question. First, a synopsis (original thread started at 5/30/2006 with the same subject line): I was unable to use $xwiki.copyDocument successfully, because an XWiki.XWikiRights object for XWiki.XWikiAdminGroup contained a bogus field named 'levelsye' instead of 'levels' as the object description shows. This caused an aborted transaction when saving the new document, which was not logged, complicating the debugging process. Further, the entire document save did not abort, leaving a new document with its content but no objects. Since the documents being copied were user profile documents, this was slightly problematic, to say the least. Unable to get the scripts to work (this was an attempt to migrate the wiki to a different authentication scheme, requiring a different standard for user names), we then simply created new users and bulk updated the database to replace all references to their old names with the new versions, and everything was fine. I had confirmed that the bogus fieldname was the problem by adding a rights object by hand, which of course had the correct schema, and deleting the old one. The document copy worked correctly, objects and all. So I went into the database to change all the bogus fieldnames in xwikistrings (which required deleting and re-adding, since the name participates in its primary key). That's when all kinds of things started breaking. I got an error saying (roughly) that there was no instance of the 'levelsye' field for the object being saved(and I wasn't saving any objects that I knew of), so I re-added them and let it alone. Since then, having delved further into the database schema, I realized that the problem was that, because XWiki saves the schema by which an object was created, there was yet another place I hadn't found where the errant fieldname was stored - xwikiproperties. Interestingly, a note by Robin Fernandez in a Feb 19 query on the email notification plugin showed this bogus property in his database, and he noted problems with saving a document... Finally, on looking at the code, I have discovered that the 'levelsye' fieldname is not only found in the database, but it is created by XWiki.ProtectUserPage, which is called by createUser. Ludovic confirmed that the database content was indeed a bug, so it looks like I have the following bugs to report: 1. The database load for 0.9.840 has 'levelsye' in several places, which should be 'levels'; 2. com.xpn.xwiki.XWiki.ProtectUserPage() perpetuates this error. When copying objects fails as a result of the above, copyDocument 3. incorrectly returns success; 4. does not log the failure; 5. does not back out the transaction that created the copy, leaving an improper copy of the document which looks correct to the user who called copyDocument() because 6. the cache is not refreshed. The question: is this correct, and if so should I report these bugs as one, as six, or something in between? brain[sic]