Jeremie (and Ludovic):
I
don't know whether this has been fixed yet, but in 0.9.840 if you copy a user's
profile page (the one created by XWiki.createUser()) the object copy fails
silently (transaction aborted). If your code examines the copied
document immediately from the same session, without clearing the cache, it looks
right, but after calling $xwiki.flushCache(), or viewing the document from any
other session, only an empty template shows, with no XWiki.XWikiUsers object to
display and no XWiki.XWikiRights objects.
The
object copy fails because one of them - the XWikiRights object for
XWiki.XWikiAdminGroup, which was created by XWiki.ProtectUserPage() when
the user was created - contains a field "levelsye" which is not in the current
schema for objects of class XWiki.XWikiRights, which names the field "levels"
instead. And it also doesn't matter if the user was created by your wiki
instance after installation or if it came built-in with the database
installation; the default users are also corrupted this way.
I must
apologize: I probably should have filed a bug on this, but I
didn't. It wasn't initially clear to me what the status of it was, and
since the job I was trying to do was my major priority, I didn't take the time
to find out. But I think it's two bugs - actually three from the
standpoint of the delivered product - because the database load contains the
result of one of the errors in the code:
- first, the root cause: XWiki.ProtectUserPage creates an
XWiki.XWikiRights object with a "groups" field with value "XWiki.XWikiAdmin", a
field named "levelsye" with the value from its userRights parameter, and "allow"
value of 1. This object cannot be copied to another page, because the
"levelsye" field is not in the current schema for
XWiki.XWikiRights.
- second: the 0.9.2 database upload contains the result of
this problem in all of its built-in user profile documents. I had thought
that this was the source of the problem, and that all new users simply had the
defective rights object copied from one of those, until I discovered the above
problem.
- finally, the resulting problem that I had when changing XWiki's
authentication scheme, which required existing users to be renamed: When
the attempt (within XWiki.copyDocument()) to add the new object to the new
document fails because of the above, no error indication is given, and the
document copy transaction doesn't abort, roll back or return a failure
status. Moreover, the cache (at least for the current session) now holds a
copy of the new document, composed as expected, so any attempt by
the calling page to verify the copy without first flushing the cache
seems to succeed.
I
think I asked whether my characterization of this problem was correct,
but didn't get a response. Probably I should simply have filed it as
a bug and let the developers correct me if I was wrong. To avoid a problem
of this sort in the future, I think that perhaps the best protocol would be
that I file it unless someone objects; that would make sure that it was
accounted for.
brain[sic]
Hello,
I believe you can use the copyDocument() method. I use it
to rename pages, I copy a document to a newly named document, then delete
the old one.
All objects and attachments are also copied in the
process, so that may interest you (as far as all objects are included in the
template document I believe)
$xwiki.copyDocument($sourceDoc,
$targetDoc)
Jeremie, Bousquet
GSE Solution
CMO
Gemalto
Tel:
+33 4 42 36 42 93
Avenue du Jujubier, Z.I Athelia IV
13705 La Ciotat,
FRANCE
Jeremie.Bousquet@gemalto.com
www.gemalto.com
Hi All,
Is there any way to clone all objects in an
existing document to a different document with one server request?
So that a template document can be maintained
with default object values; and can be brought in painlessly to a new
document.
Brandon
Esbach
Software Engineer
M/A-Com Eurotec
Operations
LoughMahon Technology Park,
Skehard
Road,
Blackrock,
Cork, Ireland
Tel +353 21
4808305