Edgewall Software
Modify

Opened 10 years ago

Last modified 4 months ago

#9222 new enhancement

"full delete" of wiki page could be a non-fatal operation

Reported by: team@… Owned by:
Priority: normal Milestone: next-dev-1.5.x
Component: wiki system Version:
Severity: normal Keywords: patch
Cc: erne.castro@…, mmitar@…, Ryan J Ollos Branch:
Release Notes:
API Changes:

Description

When I delete a file from SVN, it stays there in previous versions. Would be nice to have the same possibility in Trac (maybe configured from trac.ini):

When I delete a page from Wiki, it goes off and I don't see it in Index and I can't reach it from web. But I can reach its previous versions! I just deleted the page in version 5. When I go to this page from web - Trac says that the page is absent and asks me whether I want to create it. But when I go to this page with @5 suffix, I get directly to the deleted page, its latest version.

Such a behavior looks more effective/consistent for me, than "full delete", as it is now.

Attachments (1)

trashable_meta_wiki.diff (2.8 KB ) - added by benjamin.a.lau@… 9 years ago.
Adam Piper's trashable_meta_wiki patch

Download all attachments as: .zip

Change History (20)

comment:1 by Remy Blank, 10 years ago

Component: generalwiki system
Milestone: next-major-0.1X

That's an interesting idea, too. It might be superseded by #1132, if the latter is implemented earlier.

comment:2 by Christian Boos, 10 years ago

I'm interested as well. We could mark the page as deleted, and filter it out from things like the page index.

In the user interface, this could become the default behavior (as it's safer) and the old behavior could be obtained when checking a Really delete the page from the database and purge all existing versions option. It's still useful to keep that possibility around for cleaning up spam damage for example.

In the current schema, this can be simply done by abusing the readonly integer field. In a newer schema, that should be a status field on its own.

Ah yes, and this would enable us to implement the wiki part of #6744.

comment:3 by Christian Boos, 9 years ago

Owner: set to Christian Boos

comment:4 by erne.castro@…, 9 years ago

This is really interesting.

We use Trac at our organization and within a fairly large group of developers (~60) and clients.

As permission managing can be a nightmare we try to be very "open" in this aspect and, in our SVN we allow everybody (does not matter seniority) to have read+write access to it (except */tags/* of course). This is basically because no hard damage can be made as you can always rollback any SVN operation.

In Trac, in the other hand, we have to be a lot more careful about permission delegation as a "DELETE PAGE", "DELETE ATTACHMENT" or "DELETE VERSION" is always a one way operation, you just can undo that.

It would be, from my point of view, a huge competetive advantage to have something like SVN for wikis and attachments.

Of course, it would be a plus if there still remains and options (maybe through trac-admin) to complete purge a wiki page or attachment.

BTW, it would be nice to be able to purge tickets too… as sometimes somebody creates 5 tickets just for testing

comment:5 by erne.castro <erne.castro@…>, 9 years ago

Cc: erne.castro@… added

in reply to:  4 comment:6 by Remy Blank, 9 years ago

Replying to erne.castro@…:

BTW, it would be nice to be able to purge tickets too… as sometimes somebody creates 5 tickets just for testing

Add the following to your trac.ini, and TICKET_ADMIN will be able to delete ticket comments and complete tickets. Requires 0.12.

[components]
tracopt.ticket.deleter.* = enabled

comment:7 by adam.piper@…, 9 years ago

I've create a patch to address the content of that thread. The patch now requires the following query to be executed against an existing database:

ALTER TABLE wiki ADD COLUMN deleted datetime NULL;

It will then never allow a full deletion of a wiki page. I appreciate that full deletion might be required in some cases such as spam cleanup, and based upon feedback from this issue thread I'll try to decide how to take this forwards. Do you have any suggestions?

I have cross-posted this on http://groups.google.com/group/trac-dev/browse_thread/thread/c7bca62f8eda29b7/f415d447af0a1c18 — the patch is attached to my 3rd mail.

Best regards, Adam Piper

comment:8 by Ryan J Ollos <ryano@…>, 9 years ago

Cc: ryano@… added

by benjamin.a.lau@…, 9 years ago

Attachment: trashable_meta_wiki.diff added

Adam Piper's trashable_meta_wiki patch

comment:9 by anonymous, 9 years ago

Keywords: patch added

I thought it would be useful to have the patch attached to this ticket. I've also addded the patch keyword since there seems to be some kind of convention for doing that.

comment:10 by adam.piper@…, 9 years ago

I have supplied an updated patch to the mailing list linked above.

Is there any chance of this being merged into Trac?

comment:11 by Christian Boos, 9 years ago

Looks like a promising start… the next steps would be:

  • we would need an upgrade step for the database to add the new column (but … see below)
  • in the delete dialog, we would need to present the user with a choice to either physically delete the page, or to mark it as deleted (probably via a Purge from the database checkbox, with a hint explaining that a purge will remove all the history and there will be no "event" showing the deletion of a page)
  • the delete code should therefore keep the DELETE in addition to the new UPDATE (e.g. add a flag purge=False, if True do a DELETE)
  • we should really make sure that all the SQL dealing with the wiki table really knows about the deleted flag (e.g. timeline and search queries)

Now some thoughts about the upgrade part. Trac 0.13dev will likely see a lot of db upgrades; doing them sequentially the "regular" way (incrementing system.database_version) will be problematic, as each branch will have its own db_version = 27 (like source:ticket-links/trac/db_default.py@8191e68b9082), and this is painful. I think we should find a more fine-grained way to do db uprades, for example each module that needs it could maintain its own db version (e.g. wiki_db_version). Feel free to come up with something in this direction, but otherwise I'll take care of it.

in reply to:  11 comment:12 by Remy Blank, 9 years ago

Replying to cboos:

I think we should find a more fine-grained way to do db uprades, for example each module that needs it could maintain its own db version (e.g. wiki_db_version).

This is related to #8172.

in reply to:  11 comment:13 by Adam Piper <adam.piper@…>, 9 years ago

Replying to cboos:

Looks like a promising start… the next steps would be:

  1. we would need an upgrade step for the database to add the new column (but … see below)
  2. in the delete dialog, we would need to present the user with a choice to either physically delete the page, or to mark it as deleted (probably via a Purge from the database checkbox, with a hint explaining that a purge will remove all the history and there will be no "event" showing the deletion of a page)
  3. the delete code should therefore keep the DELETE in addition to the new UPDATE (e.g. add a flag purge=False, if True do a DELETE)
  4. we should really make sure that all the SQL dealing with the wiki table really knows about the deleted flag (e.g. timeline and search queries)

Hi Christian,

I have supplied an updated patch, attached to http://groups.google.com/group/trac-dev/msg/dfcf37966de3c247, this addresses points (1) and (4) above.

Best regards, Adam Piper

comment:14 by Mitar, 9 years ago

Cc: mmitar@… added

comment:16 by Ryan J Ollos, 5 years ago

Cc: Ryan J Ollos added; ryano@… removed

comment:17 by Ryan J Ollos, 5 years ago

Owner: Christian Boos removed

comment:18 by Ryan J Ollos, 4 years ago

Milestone: next-major-releasesnext-dev-1.1.x

comment:19 by Ryan J Ollos, 4 years ago

Milestone: next-dev-1.1.xnext-dev-1.3.x

comment:20 by Ryan J Ollos, 4 months ago

Milestone: next-dev-1.3.xnext-dev-1.5.x

Milestone renamed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned. Next status will be 'new'.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.