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 <blah blah blah process>". 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 <blah blah blah process>". 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 <blah blah blah process>". 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 ... On Wednesday, September 8, 2021 at 7:18:31 AM UTC-3 jeremy...@gmail.com wrote: > 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: > > * At the moment, write operations cannot fail, and so there is no error > handling in wikitext. If we introduce operations that can fail it seems > likely that we'd also have to incorporate error handling features, which > would considerably complicate even simple operations > * Performing the access control lookups would have an impact on > performance. The core is architected so that lookup operations on the > tiddler store are as fast as possible (a single JS object lookup), and so > adding even a little bit more logic will end up multiplying the overall > execution time of the store component many times over > > 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 > > On Tuesday, September 7, 2021 at 1:09:01 AM UTC+1 cj.v...@gmail.com wrote: > >> 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': >> >> - delete button >> - drag and drop a crap version that overwrites the good version >> - bad set-field (or other action widget) that deletes a tiddler, or >> completely/partially overwrites the tiddler >> >> I'm sure there are other Darwin Award moments, like creating and saving a >> new tiddler with the name of an already existing tiddler, and being just >> plain old too numb-in-the-moment-deer-in-the-headlights to really clue into >> the pending "this is going to leave a scar" moment. >> >> 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. >> >> >> >> On Monday, September 6, 2021 at 8:50:16 PM UTC-3 TW Tones wrote: >> >>> 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 >>> >>> >>> On Monday, 6 September 2021 at 19:07:42 UTC+10 PMario wrote: >>> >>>> On Monday, September 6, 2021 at 3:01:25 AM UTC+2 cj.v...@gmail.com >>>> wrote: >>>> >>>> No worries. I'll train my thoughts on obfuscation, risk-mitigation >>>>> design/strategies, and automated monitoring/repairing processes. >>>>> >>>> >>>> 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 >>>> >>>> -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/5d6b4233-134b-4df0-aedf-d2c982f42640n%40googlegroups.com.
