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. On Monday, September 6, 2021 at 2:34:45 AM UTC-3 TW Tones wrote: > 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 > > On Monday, 6 September 2021 at 15:15:49 UTC+10 [email protected] wrote: > >> 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 ! >> On Monday, September 6, 2021 at 1:03:27 AM UTC-3 TW Tones wrote: >> >>> 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 >>> >>> On Monday, 6 September 2021 at 11:01:25 UTC+10 [email protected] wrote: >>> >>>> 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: >>>> >>>> - A brewing idea: TiddlyWiki on node.js: check for changes >>>> <https://groups.google.com/g/tiddlywiki/c/GMagvXTOxLI/m/POV20R69AwAJ> >>>> - More playing around with TiddlyWiki on node.js: the makings of a >>>> distributed database >>>> <https://groups.google.com/g/tiddlywiki/c/OuYwkSgPBDo/m/egsk9fhoAwAJ> >>>> >>>> On Sunday, September 5, 2021 at 8:18:19 PM UTC-3 PMario wrote: >>>> >>>>> On Sunday, September 5, 2021 at 8:36:26 PM UTC+2 [email protected] >>>>> wrote: >>>>> ... >>>>> >>>>>> 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 >>>>> >>>>> >>>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/1983fb83-3765-439f-8ccd-6c445feee576n%40googlegroups.com.
