Relink should be configurable on what tiddlers it modifies

[flibbles]

Currently, Relink modifies all tiddlers, including system tiddlers. It needs a way to modify this.

So I've introduced $:/config/flibbles/relink/to-update, a system tiddler that, if exists, Relink will use its text as a filter to determine what's eligible for an update.

This issue has other parts to it I haven't addressed yet.

• Maybe there should be a way to specify tiddlers Relink should ignore if it's renamed.
• Maybe there should be a General configuration page for one, or both, of these settings
• Need to make sure that Relink's filter operators work consistently with these system configurations. Currently, [relink:references[]] ignores it. I think it should and that the rename filter should be [all[relinkable]relink:references[]] to determine what to update.

[AnthonyMuscio]

Thanks for this work.

Just to clarify, the filter you have stated building is the second of these two?

As I understand The two possible filters would be

• If the filter permits, display the check mark option to relink tiddlers containing this name
• If the filter permits, only modify tiddler title changes in tiddlers that meet this filter

An example of the second filter may be [!prefix[$:/trashbin]] OR [!is[system]] in other words to not change any reference found in system tiddlers to the renamed tiddler .

So example filters of the first type would be ?

[!is[system]] exclude system tiddlers [is[tiddler]] include only regular tiddlers [has:field[object-type]] has the object-type field empty or not, any value [object-type[person]] [object-type[office]] shows relink option on tiddlers with person OR office object-types [tag[relink-allowed]] has the relink tag then allow relink, otherwise do not relink [!tag[!no-relink]] has the no-relink tag do not relink, otherwise then allow relink

Or will the above need to start with [all[current].. ?

[flibbles]

You are correct with the examples for the second filter. I implemented it as an whitelisting filter rather than a blacklisting one, since it seemed more intuitive to have Tiddlywiki works.

I haven't implemented the first filter yet, but the examples you've given are all correct (except maybe [is[tiddler]] since that includes system tiddlers too).

I have not implemented the presence of currentTiddler for either filter yet, and won't unless it's needed. If the filters are allowed to be dependent on that, it eliminates the possibility of having filter generators like [all[relinkable]] which I would prefer to use for obtaining a list of tiddlers to update.

[flibbles]

By the way @AnthonyMuscio, was this sufficient? Do you still need the ability to alter what tiddlers get the option to be relinked on rename?

[AnthonyMuscio]

@flibbles I think we could alter what tiddlers get the option to be relinked on rename quite easily. It can use the same mechanism we use to conditionally display items on the view template. Assuming by not displaying it nothing will happen.

The most common use may be to rename and relink inhibit $:/ system tiddlers. But on completed application we may want to only rule in some tiddlers eg "[all[current]object-type[person]] [all[current]object-type[office]]" so only office and person tiddlers permit relink.

eg

<$list filter={{relinkfiltertiddler}} valuable=nul>
Display relink here
</$list>

However of late I have found using an intermediate variable can be helpful because it can be overridden locally

\define relink-filter() {{relinkfiltertiddler}}

<$list filter=<<relinkfilter>> valuable=nul>
Display relink here
</$list>

Hinted at here is my desire to also develop a rename inhibit where tiddlers flagged as such will not even display the edit title field in edit mode, and a supporting delete inhibit, where the delete button is hidden from view and edit toolbars.

[flibbles]

Looks like there's a complication here.

If fromTiddler meets the filter, but toTiddler doesn't, or vice versa, behavior is hard to make consistent.

There are actually two places where the to-rename filter must be used. One, where you've pointed out, to hide or display the checkbox. Two, in the rename hook function. Because even if the checkbox isn't displayed, it may still be checked (from, say, another tiddler being renamed).

Ordinarily, that's not a problem, just run the filter twice. But at the time when the title EditTemplate runs, the existing tiddler is still named fromTiddler. When the rename-callback-function runs, the tiddler is now named toTiddler. Different circumstances. If one passes the filter, but the other doesn't, you have a case where the checkbox may be displayed, but no relinking occurs, or no checkbox shows up, and relinking happens anyway.

A possible solution might be to switch the checkbox state tiddler over to be per-tiddler rather than global, automatically set that state to false for non-passing tiddlers, and then have the callback-method check that state rather than the filter again. ...but that doesn't address the problem of when tiddlers are renamed programmatically, such as through the tw5-commander plugin. The title EditTemplate won't get run in that case, so tiddlers that shouldn't be renamed may still get renamed in rare cases.

So yeah, turns out it's not trivial. Still trying to puzzle out how this should be done, if at all. What was your use case again? Your users have the authority to rename a tiddler, but not have any other tiddlers be renamed as a result? But why? I guess I'm having trouble envisioning an authorization issue that a to-rename filter would cover, but to-update doesn't.

[flibbles]

I've decided to close this issue.

• to-update is already implemented, which I think should cover most bases.
• to-rename has a lot of underlying complexity. Without a clear direction for how it should operate, I'm not sure its worth the effort, particularly given how small of a portion of the userbase would actually use it.
  • As far as I can tell, to-rename would only be useful in a multi-user environment with tiered levels of authorization. That has to be the 1% of the 1% for Tiddlywiki.

[AnthonyMuscio]

@flibbles I am fine with that, and its your decision to make. I still believe there would be great value in doing so but understand I was not clear enough and did not spell out the value.

I have come to realise that what I was asking for would be better suited to a package of other tools designed to inhibit various activities in tiddlywiki. For example, rename or edit inhibit on published wikis, where users do have write permissions. So I will persue that approach, and since If I inhibit renames, It will as a result inhibit relinking.

In closing this is a most brilliant and in demand solution which you have solved perhaps for the first time in a decade.

I need not raise an issue for this here, but your solution does overwrite a handful of core tiddlers and this is not the most desirable method, there should be a hackable method available to you within the standard tiddlywiki, so you can add this feature without core tiddler override, so your plugin does not introduce issues if any of those core tiddlers a re rewritten in the future.

I will endeavour to have such hackability introduced so keep and "ear out" for such changes, then you can re-release your wonderful plugin using the hackable option and avoid over-writing core tiddlers. Of course your input to this would be appreciated, as you have already at https://github.com/Jermolene/TiddlyWiki5/issues/3649

Regards Tony