Recycle Bin in Sitefinity 7.1
Hi all,
Sitefinity 7.1 will include Recycle Bin, a feature which will lists all deleted content in a dedicated section of the Backned, plus the ability to restore deleted items.
We are interested in knowing more about your requirements in regards to this feature, and more specifically:
We look forward to receiving your feedback!
You can subscribe to this thread to follow updates on this functionality, and see preview of the wireframes.
Dear Kali
Let me start of by saying this is wonderful news.
To me the most important thing is to prevent my clients from making damage. So Design - Pages and Widget would be on my wish list.
Access to recycle bin to me would make sense for
- all administrators
- to whom has deleted an item (they should only see their items. If they can delete it they should be able to restore it.
Will there be a clean-up possibility. Like empty recycle bin?
This would be nice. Now the history is filling up the database without much we can do. (hoping 7.2 will bring the option to limit the numbers of history that are kept.
And I would not want to have the same 'problem' with recylce bin.
One of the features I would love to see in SF, a bit off topic to a degree, is a way of integrating the Widgets code that we see in thunder, but being able to have them into TFS or SVN, so even that when we are using thunder the content would be controlled by one of those source code providers.
Hello,
As I have in other CMS that I use, for me the most interest regarding the trash can is also about pages (with all on it) and various contents.
About security, I suppose that every one must be able to restore it's own deleted stuff and the admin any stuff. If it is also a purge (empty etc.) facility I think that it must be available only to admin.
off topic
I don't know if this available now (if is, sorry), but I find nice to have a property, let say, "Visible" for pages and specially for content (e.g. we have added a news or event item, but not sure if is something sure, so we need to keep the item invisible to the time when is approved)
I would like to see which user deleted the page (Date/Time etc..).
All Administrator roles.
Something that I think would be beneficial would be the ability to define a purge setting to allow the admin to setup the amount of time that the pages would stay in the recycle bin (perhaps in days).
@Tim
I rather have someone purge it then have it cleared after some days. Someone deletes a page and goes on vaction or so. But I could agree that it would be nice if you could delete all contents deleted n days or older.
Markus
@Kali
Like.
For me, widgets are a must and administrators should have the ability to see all items and see who put them in there. Ability to set who has access to remove items from the bin would be nice, but admins should be priority.
+1 for the other extras that Steve outlined.
Okay we need to just make a distinction here...widget TEMPLATES need to be in the bin...not widgets on pages. That exists already as revision history, and the person who edited the page is listed in the history already.
I think there was another post about an audit log feature, I think thats what some of you guys are wanting instead? Can't really put a widget in the recycle bin as its not technically content.
...also @Kali...dash widget for recyclebin activity would be slick too
This is closely related to the recycle bin feature -- would like to see the possibility to associate the delete action to a workflow. So, deletes would follow the same approval process as any other content publishing.
Hi all,
And thanks for the valuable input! Your ideas all make sense and we’ll try to incorporate them in the development. Our plan for phase 1 is to focus on Pages and Content as these are the most critical areas where recycle bin is needed.
Please, let us know how you’d prioritize the requirements below. In your opinion, which ones are MUST for iteration one, and which ones can wait for next iterations:
I look forward to receiving your feedback.
Let me know if further clarification is needed.
Regards,
Kalina
Must
Recycle Bin for Page Templates
Recycle Bin for Widget Templates
Markus
1) Recycle Bin for Widget Templates
<These should all be mandatory>
<reason>Its not "undeleting" and restoring content if the following do not happen right</reason>
1) If a news item is related to an image, and the news is deleted and then restored, link to the image should be restored as well
2) If a news item is related to an event, and the news is deleted and then restored, the link to the event should be restored as well
3) If a taxon (tag or category) is related to a content items (i.e. news), and is deleted and then restored, the link to content items should be restored as well
</These should all be mandatory>
2) Recycle Bin for Page Templates (I don't see this being much of an issue, as you cant delete a template with pages using it)
@Markus
Page templates isn't a "Must"...someone would have to edit every single page against a template, CHANGE the template they're using until no pages are on that template...THEN delete it. That takes some doing and if someone goes ahead and does that they're digging their own grave. Recycle bin should be more for like "Accidents".,,primarily anyway
@Steve
You are 100% correct on that remark.
It would only make sense if the site is under development and you make a mistake. I guess its not possible to delete a page template that has no pages but is the base for other templates.
For my clients is mostly the accidental page delete to be undone.
Markus
Yeah, no it's CLEARLY needed...just not urgent like the other things
Hi all,
And thank you all for the helpful ideas and insights!
You can see the wireframes for Recycle Bin feature on this link.
This is what version 7.1 will include:
Older items will be permanently deleted automatically.
In Recycle Bin, option to preview, delete forever and restore items. Admins can restore all items, regular users can restore only the items deleted by them.
Recycle Bin support for Pages (including Multilingual)
There are some questions on which your input will be appreciated:
On Restoring the Status
When restoring an item which was in a certain Status prior to deletion, do you expect the item to be restored in the original Status, or should it be restored to Draft status instead?
To illustrate: if Page1 was Published, and then deleted, if the user restores it in Recycle Bin, do you expect Page1 to be restored as Published or as Draft?
What about if Page1 was Approved (in approval workflow), Published, and then deleted? When restored, do you expect it to go back to Published status, or should it go through the Approval workflow again?
What about if Page 1 was Scheduled for Publishing on day X and then deleted? If user tries to restore it on Day X+1, should the page be restored as Published or Draft?
On Restoring Translations (in Multilingual)
How often in your practice is the case when users delete one translation of a page (say in German) and then they’d like to restore it? Do you think covering for such scenarios is critical for 7.1. release.
Other comments or suggestions are welcome!
We look forward to receiving your feedback,
Regards,
Kalina
Sitefinity Team
Kali,
What about ecommerce products? Will they go through the recycle bin?
Craig
On Restoring Status
- I would expect it to restore in the state it was deleted in. I'm just well aware that our admins will restore content and think everything is good...not go in to re-publish it....
- If it was approved and published I would expect it to be restored as such and not go through approval again...if nothing has changed with it. Will there not be an "undelete" workflow step where we can approve undeletes (if need be)?
- Scheduled...no idea, I defer this one :) I PERSONALLY would want it to be restored in draft...if it was never live content...well...I mean I wouldn't want it to pop in suddenly 80 days later if someone is screwing with the recycle bin.
Translations: No Feedback, dont use it much
Comments:
- Love the little recycle bin icon on the sidebar
- Love the "Undo" function
- No option for us packrats to keep things indefinably?...has to be a set number of days?
- Dashboard icon is a bit much...does it really need to be there, can't it just be on the admin menu or something?
- Can we contextualize the messages so it's not "Are you sure you want to delete this item" it says the item you're deleting...like when you delete a column from the module builder it's bold and red...you fully know what you're doing.
- I like that the TYPES are fully listed in the recycle bin...not like comments where they're hidden behind an extra click...I hope not only this stays that way, but comments uses this method as well.
- LOOKS GOOD!
I would rather see pages restored as draft unless on undo.
it might be more work for users but less hassle programming wise for Telerik
- New page with same URL exist
- Parent page missing putting it a top level (would not be nice to see someting appear in top navigation suddenly
- Pages about to be published in the past would be resorted without beeing active
-- it would be able to skip workflow
- Content might still be to be worked over. Lets say someone deleted an store location page and wants it restored as base for a new store location or whatever.
Markus
Re: Restoring Statuses
I believe all use cases for the recycle bin should focus on fixing mistakes and should not at all be treated or perceived as an alternative to unpublishing. (Perhaps the default auto-purge duration should take this into account and be 30 days or less.) Because of that I think statuses should be restored when restoring items, rather than mimick the behaviour of republishing. If there's one thing my users are prone to complain about, it's extra steps in a process. In this case the process is "undoing a deletion that should not have been performed."
My preferred middle ground on the topic of restored statuses would be to provide two restoration actions per item: one to restore in last state and one to restore as draft. "Restore as draft" could logically be the automatic fallback path when an exceptional condition such as "missing parent" is encountered. In these cases, restoring as draft provides opportunity to properly address the situation.
Bonus: if both restoration actions get implemented, provide a setting that allows "restore in last state" to be enabled/disabled per application. That would allow very workflow-conscience sites to enforce their strong workflow rules.
Re: Permission to Restore
I would strongly prefer that some non-admin non-owners also be allowed access to restore deleted items. In my case there are multiple non-admin users per section of the site and I would prefer that coworkers be allowed to fix mistakes without calling me. Perhaps anyone who has the permission to delete an item also has the permission to restore that item?
-Chris
@Chris "I believe all use cases for the recycle
bin should focus on fixing mistakes and should not at all be treated or
perceived as an alternative to unpublishing"
NAIL ON THE HEAD!
@Markus
That's a bit of a huge assumption that it's LESS work for telerik. I dont see how restoring an item with the same status it was deleted with is more work than changing it's status to draft....and if "Recycled" becomes a new status it's all being changed anyway regardless.
Please also make sure anything in the recycle bin is hidden from search engine crawlers.
Thanks!
Requirements
I know I'm late to this thread but I'd like to know if this feature will be fully supported by the sync. I'd think this isn't really related to the sync (i.e. as soon as it goes to publish it will be ready for sync), but just want to make sure you guys don't forget about this. Also, need to make sure you guys provide full support for dynamic modules as we are heavily invested in that.
About ur questions:
On Restoring the Status
Just as someone suggested: I'd expect it to restore in draft mode unless doing an "undo". It could be a bit dangerous for us having something restored and directly showing up in the live site. We might want to do some adjustments prior to publishing it (and would like to have it go thru the WF approval process again to be safe). I'd "reset" the scheduling settings, as if it was never scheduled.
On Restoring Translations (in Multilingual)
Everyone is en and fr to us so i'd be ideal that this feature supported multilang. Not critical though.