Say I have a tiddler that must not be overwritten by things such as:
Is there an easy way to protect such a tiddler?
…
Is there an easy way to protect such a tiddler?
No. In TW you can overwrite every core tiddler if you like. So there is no way to write-protect a tiddler.
What do you want to achieve?
-m
Trying to achieve a robust architecture for a farm of node.js TiddlyWikis that together form a distributed database, with end-user level (and private) TiddlyWikis that have certain types of tiddlers that are automagically shared (and the rest private), and system-level TiddlyWikis that tie all of the architecture together along with user-interface stuff, etc. etc. etc.
Sure, not very likely end-user folk could muck things up, but a robust system really should never allow an end-user to break their TiddlyWiki (in this farm idea of mine) by somehow replacing any key component tiddler.
No worries. I’ll train my thoughts on obfuscation, risk-mitigation design/strategies, and automated monitoring/repairing processes.
All part of a big idea that ties together, in part:
Charlie,
A few ideas;
One way would be to stash a copy away, perhaps inside a JSON tiddler, similar to Mohammad’s trash plugin but just on editing. This kind of solution can intercept User interface edit/delete however batch processes can by pass this.
Some solutions like noteself to keep all versions, so you could restore from there, after running an automated are tiddlers missing check, perhaps before saving.
You could also modify the delete button to refuse to delete if a tiddler contains a field delete-inhibit=yes or just exists. I have already made an alternate edit button which honors edit-inhibit and just hide the original edit behind the more button. On some wikis we may want to hide the more button so they can not access (directly) the buttons we do not want them to use and only provide them alternatives, we want them to use. When the cant edit or delete you can actually just hide that alternative button.
Another is to take a set of tiddlers, and move them into a plugin, delete the tiddler version. They then become shadows, and if edited you simply delete the tiddler to return to the shadow copy. The only way to delete the shadows is to delete the plugin itself, so the user needs to undertake additional steps. This can avoid batch processes deleting the tiddlers.
I have felt that for some time introducing delete-inhibit and edit-inhibit fields/flags on at least some tiddlers would be a helpful option. For example the plugin mentioned in the last paragraph.
I am yet to work out how but I believe the new eventCatcher widget or the existing LinkCatcherWidget or ActionConfirmWidget can help here.
One idea would be trapping using the action confirm widget on the delete step, and on confirmation make a backup copy of the tiddler.
Tones
G’day Tones,
I’ve got editing and delete of important tiddlers blocked via tiddler locking. That’s easy and good.
The only thing I have to handle, even if 99% unlikely, is certain tiddlers getting overwritten by any tech-savvy (well, TiddlyWiki-savvy) individual.
Since that can’t really be prevented, then a scheduled process to compare files should be pretty easy (for all of these TiddlyWiki instances on node.js) Just a matter of comparing “end-user” tiddlers to "architecture/infrastructure/farm/admin/etc .) tiddlers, and having the process delete anything that shouldn’t exist in end-users’ tiddler folders.
Maybe another little process to raise the redflag as soon as there’s a blip.
I am avoiding plugins and staying pure node.js and tiddlywiki for as much as I can, an exercise to really get a good feel for how TiddlyWiki works on node.js. For the near future.
All of these goodies you mention in my back-pocket for now. Thanks !
Charlie,
Good to hear. Since you question was answered with “Tiddly locking” could you point to that as a solution for future readers in this thread ?
Tones
Well, “Tiddly Locking” isn’t a solution to my problem in this thread.
My problem is about preventing tiddlers from being overwritten by an import or by a new tiddler getting created and saved with a name of a tiddler that already exists. That’s not solved.
Tiddly Locking is great, is something I use, but has nothing to do with this thread.
Charlie,
My problem is about preventing tiddlers from being overwritten by an import or by a new tiddler getting created and saved with a name of a tiddler that already exists. That’s not solved.
But in my earlier reply, I think we can solve this issue by moving the “readonly” tiddlers to a plugin where they become shadow tiddlers. Effectively thus protected tiddlers, Unless the plugin is deleted they will always be there “in the shadows”, it would then be simple to detect any edited tiddlers and delete the update reverting to the shadow. Keep in mind the shadow tiddlers can be any name not just system tiddlers.
I can pursue this for you if you want?
I would make;
Regards
Tones
IMO obfuscation is wasting time, other than removing the buttons, that are not needed. Which I would define as “modifying the UI according to the usecase” 
With nodejs you should be able to establish a “batch process” that runs once a day and checks, if some important shadow tiddlers have been overwritten. I would consider this as “Plan B”.
Plan A - IMO the easiest way would be to trust your users and tell them what’s going on, and what’s important. Having Plan B will then only be needed if someone changes something by accident.
just a thought
mario
Oh, don’t pursue that for my sake. I’ve got something in mind already that I want to try out.
Well, by obfuscation, I see that as a catch-all word to also mean abstraction, encapsulation, and whatever other little design thingies so that the end result doesn’t look anything like TiddlyWiki any more.
So a user will have to work very hard to get into trouble.
Your Plan B is my Plan A, and your Plan A is my plan Z. In my mind, folk who are busy with their missions don’t need to be distracted by technical stuff needed to be kept in mind. The best kind of software is the kind that doesn’t need any user guide other than, maybe, something concise that lets them know how the software supports them, their goals, their processes. I prefer that users trust that software they work with is robust/resilient/etc. and doesn’t ever waste their time by allowing something to happen that can waste their time. Well, within reason. That find balance of cost/benefit.
But I do suffer easily from both sensory and cognitive overload, and so heavily do these influence my design philosophies.
Charlie:
Perhaps some of the protection you are looking for can be had via the frequent saves of a tiddler file to Dropbox?
Unless things have changed since I last used it, that would provide a rolling 30 day cache that could be used to recover losses.
Cheers,
Hans
What I have in mind is pretty simple, and it is about resolving issues that completely break TiddlyWiki or break an application built upon TiddlyWiki in a node.js farm of TiddlyWikis.
On Talk.tiddlywiki.com I would mention Mario and Charlie here.
Mario I would like to support part of what Charlie seems to be concerned with. I have a few wikis where I have delete inhibit on selected tiddlers, typically the master tiddler that is a compound tiddler, meaning it has many subtiddlers. Deleting that would result in loss. I have the real delete button behind more, so I can get to it. I also have edit inhibit because I rarely change the master tiddler but want to edit the subtiddlers. A conditional edit button simply helps stop me clicking on the wrong edit button. All this can be circumvented, but it helps improve the user Interface by avoiding the display of buttons that are not relevant and could initiate actions that cause a waste of time if not damage.
Tones
Just to re-iterate, there are several ways an important tiddler can be unintentionally fricasseed.
The most likely from a brain-fart moment, examples off the top o’ me noggin’:
Just when one thinks one can trust oneself to not pull an award-winning dumb move, the IQ-stealing fairy is waiting just around the corner for a clobbering.
Tthis is one of those reasonable sounding features that has a surprising degree of inwardness when one looks into it. Implementing true read-only tiddlers would have a substantial impact on the architecture of TiddlyWiki:
So, it was an explicit early design decision that operations on the tiddler store cannot fail. Note that client-server configurations have much more scope to block tiddler modifications being synced in one direction or the other.
Best wishes
Jeremy
Just thinking out loud…
Step 1 to safe-keep important tiddlers: add a little bit of custom code to $/core/ui/ImportListing
(Well, I am pondering over what kind of trouble I might get myself into…)
If a tiddler being imported already exists and the already existing one has a certain tag, or a certain field, or belongs in a particular list of tiddlers somewhere, then:
Disable the select checkbox, and make it unchecked. Display with the tiddler title a message along the lines of "this is a critical tiddler, and can only be replaced ".
Something like that.
Step 2: upon press of the delete button on one of these important tiddlers, popup a message along the lines of "this is a critical tiddler, and can only be deleted ".
Step 3: upon creation of a new tiddler, if the name is edited and set to the same name as some already existing tiddler that is one of these important tiddlers, then disable the save button and show somewhere a message along the lines of "this tiddler already exists and is a critical tiddler, and can only be replaced ".
And if I’m thinking about all of this, it is to give time for this sponge of mine to conceive “TW integrity” constraints, like database constraints, particularly in mind: preventing the deletion of a parent tiddler when there are child tiddler dependencies on that parent tiddler.
Something like that. The wheels are spinning …