Oh, don't pursue that for my sake. I've got something in mind already that I want to try out.
On Monday, September 6, 2021 at 3:53:44 AM UTC-3 TW Tones wrote: > 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; > > - An easy way to move a selected tiddler into the safety of a plugin, > making it a "protected tiddler". > - Provide away to detect edited "protected tiddlers" and restore them > automatically. > > Regards > Tones > > On Monday, 6 September 2021 at 15:54:13 UTC+10 cj.v...@gmail.com wrote: > >> 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 cj.v...@gmail.com 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 cj.v...@gmail.com >>>>> 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 cj.v...@gmail.com >>>>>>> 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 tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/a9922e4b-b286-41a1-b888-c8586953da60n%40googlegroups.com.
