Thanks again, Ludovic, for a quick reply. I apologize for neglecting to give you the version; I'm using 0.9.840, and calling copyDocument from a Velocity script on a wiki page. And no, I'm not getting any error messages, either on the page or in the logs, with one exception: my attempts to delete the incorrectly-copied document evoked an error message, which I didn't interpret as having to do with the objects but complained of an inconsistency in item counts (e.g. expected 1, found 0) or something similar; sorry I don't have the message now. After flushing, however, the deletion succeeded. Your suspicions sound consistent with what I've seen here. There's an update to this: I edited the original document's page permissions to add "admin, programming" to the "levels" field of the corrupted rights object, which was for XWiki.XWikiAdminGroup, and the objects survived the flush. Apparently the bogus fieldname (or, more likely, the lack of the correct one) is in some way the culprit - such as causing the transaction to abort when an object with an incorrect schema was saved. Why the document and its content (an #includeForm directive) survived the aborted transaction is a mystery in that case. So, conjecturally, (apart from the incorrect DB data) the bug, if any, is that a) no error message ensued from an aborted transaction (I'm pretty sure, though not absolutely, that the logs were silent) and b) the cache was not cleared. I am adding an $xwiki.flushCache() call to the end of my copy script, at any rate, to be sure that I'm not fooled again by objects that aren't really there. At a minimum, the database dump needs to be fixed ASAP... brain[sic]

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]