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

[team@…]

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.

[Remy Blank]

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

[Christian Boos]

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.

[erne.castro@…]

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…

[Remy Blank]

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

[adam.piper@…]

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

[benjamin.a.lau@…]

Adam Piper's trashable_meta_wiki patch

[anonymous]

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.

[adam.piper@…]

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

Is there any chance of this being merged into Trac?

[Christian Boos]

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.

[Remy Blank]

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.

[Adam Piper <adam.piper@…>]

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

[Ryan J Ollos]

Milestone renamed

[Ryan J Ollos]

Milestone renamed