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/c5073b5f-d0b0-452b-8cbe-87ad12020d52n%40googlegroups.com.
