On 01/07/2010 10:09 PM, Flavius Olaru wrote:
Thanks Sergiu,
+1 for both then,
I was thrown away by the fact that $xwiki.getDocument($docFullName) returns XWikiDocument even for a deleted document.
getDocument always returns an object (almost always, it returns null if the document exists but the user does not have access to it). If the document does not exist in the database, a new, empty document object is returned.
Now after some testing... after deleting a deleted document. i ended up with a new version in RecycleBin but now the contents of the deleted document is empty... I'll be looking for the jira issue to see if it was reported this and if not i will create one.. (Note... tested on XE 2.1.1)
It hasn't been reported.
On Thu, Jan 7, 2010 at 12:37 AM, Sergiu Dumitriu<[email protected]> wrote:
On 01/06/2010 08:15 PM, Flavius Olaru wrote:
Hi Sergiu,
I am not so sure about the second part, about the delete method on DeletedDocuments. In my view it is better to have a method for the RecycleBin like empty() that removes all DeletedDocuments and where it can be implemented also a backup system.
The empty functionality will be implemented in Velocity, as a foreach+delete.
The backup should be left to an external backup program. All entries are stored in the database, so a database backup will take care of this.
We've designed the recycle bin storage to be safe enough: not everybody can permanently delete entries, and by default there is a minimum age requirement, a document must be deleted for at least 7 days before it can be permanently removed by non-admins.
For example with delete method implemented in DeletedDocument API you might call delete twice on the same document reference... by mistake or not...
#set($mydoc = $xwiki.getDocument("MySpace.MyDocument")) ## MyDocument goes into Recycle Bin #set($ok = $mydoc.delete()) ## MyDocument removed forever... oups.. it did it again :) #set($ok = $mydoc.delete())
No, this won't happen, because $xwiki.getDocument does not return DeletedDocuments, only XWikiDocuments. If you use $xwiki.getDeletedDocument then you already know that you've obtained a document from the trash.
With delete method.. you have to check if $xwiki.getDocument returns a reference to Document or a reference to DeletedDocument and as we all know programmers tend to be lazy :)... so better throw an exception than ending up with no undo....
Maybe would be better to have it from $xwiki.emptyTrash() or $xwiki.emptyRecycleBin() or $xwiki.deleteFromTrash($docFullName) / $xwiki.deleteFromRecycleBin($docFullName)
On Wed, Jan 6, 2010 at 1:27 PM, Sergiu Dumitriu<[email protected]> wrote:
Hi devs,
In order to solve the ancient XWIKI-37 (Deleted attachments not accessible via document history) and XWIKI-2254 (Attachment recycle bin), we need an API for accessing and handling deleted attachments. Note that the functionality already exists, it only needs to be exposed.
I have implemented an API similar to the one for deleted documents: (a) the class com.xpn.xwiki.api.DeletedAttachment: - public DeletedAttachment(com.xpn.xwiki.doc.DeletedAttachment, XWikiContext); - public String getFilename(); - public String getDocName(); - public long getDocId(); - public Date getDate(); - public String getDeleter(); - public long getId(); - public boolean canUndelete(); - public boolean canDelete(); - public com.xpn.xwiki.doc.DeletedAttachment getDeletedAttachment(); - public Attachment getAttachment();
(b) 3 getDeletedAttachment(s) methods in com.xpn.xwiki.api.XWiki: - public List<DeletedAttachment> getDeletedAttachments(String docName); - public List<DeletedAttachment> getDeletedAttachments(String docName, String filename); - public DeletedAttachment getDeletedAttachment(String docName, String filename, String id); In addition, I need to find the right place for a delete() method. Since there was no delete() method for deleted documents either, I'd propose to:
(c) add delete() to the DeletedAttachment and DeletedDocument API classes. The alternative is to add it to the XWiki class.
I know that the old API should rarely be changed, since it is going to be replaced by the new model, but I think that this change is OK because: * I don't think the old API is going to be removed that soon * The change is not dangerous because it only adds new stuff, and does not modify or remove anything * The added functionality is very similar to the existing one for deleted documents, so it doesn't really add new stuff, it adds missing stuff that should have already been there for a long time. * It would be nice for our users to be able to manage deleted attachments now, not much later when the new model is fully adopted.
To sum up, I'm +1 for:
1) adding the API for deleted attachments ( see above (a) and (b) ) 2) adding a delete() method to the DeletedAttachment and DeletedDocument API classes (c).
-- Sergiu Dumitriu http://purl.org/net/sergiu/