Deleting all files from the Trash web via the shell a) effectively deletes the Trash web; and b) requires shell access.
This is definitely not user-friendly.
I think the concept of the Trash web (so far) has been that it's just another storage. Things are not really deleted.
One of the major things we first liked about TWiki was its SCM-likeness when it came to deleting stuff.
If someone is considering implementing this, please try to do it in a way that is default disabled and not easily enabled.
This is a pure enhancement in my view - in where lies the urgency?
If someone wants to empty the trash, the only way currently is to delete the files in a shell. And, as I noted, if you throw away all the files, the Trash web effectively vanishes, which is likely to cause some confusion. (Sure confused the heck out of me!)
I find the idea of the Trash web just being another storage kind of, well, odd. As a Mac user, I like that things don't get instantly deleted, but I sure wouldn't like to not be able to empty the trash when necessary. If you want to stash the stuff somewhere, fine, but an ever-expanding TWiki is not
what I want.
Hard to compare a local context (trash can) with a community context (trash web) imho.
In the usecase subset where
- A topic is in the Trash web
- The topic only has revisions done by current user
- Some arbitrary time since first revision of topic is not yet crossed
I belive it might
be ok to allow for deletion, perhaps through a new binary that could be shipped disabled.
I still don't get the Urgent part.
This is an enhancement, not urgent.
It is true that it should be possible to elide topics from Trash. However proper SCM requires that they are kept. I think TWiki is right in this respect.
"Hard to compare a local context (trash can) with a community context (trash web) imho."
For us, maybe. For the ordinary users, I disagree strongly. The only computer metaphor they associate with
is throwing things away. And, for that matter, in real life people will often throw away trash from common areas.
I have no problem with this being an admin-only feature since one hopes that an admin is capable of making this decision.
What are the thoughts behind the "Misfeature" priority? It appears to not have been doc'ed.
I removed it, as it isn't a priority, it's a protest.
It's perfectly reasonable to want to be able to empty the trash; and perfectly reasonable that someone should develop an enhancement to allow this to be done through the browser.
It was not intended as a protest. Some "features" in TWiki work as documented but are bad ideas. Enhancement implies something new; misfeature implies that there's a flaw in a current feature.
Part of the problem here is that Bugs is overloaded. (Why am I not surprised?) We have the 4.0.x branch, which is intended to have only bugfixes, and we have the
branch, which is where new stuff goes.
The fact is that
isn't a priority any more than
is, except, arguably, when someone (thanks SP
) gets a Cairo-only plugin to work in Dakar. And, in fact, one could argue that some misfeature fixes should go into the 4.0.x branch -- since the misfeature is there -- whereas I assume all Enhancements should go into the develop one (again, ignoring plugins et al).