Cloning an included tiddler should respect the chkPrivateMode user setting
Cloning an included tiddler should respect the chkPrivateMode user se…
inc plugin version number
This looks like a reasonable change?
Does the bug only present itself when clone is used programmatically. Through the default UI the right thing appears to happen?
If the privacyEdit macro is not part of the EditTemplate it comes up, since the macro fixes the problem.
<div class="box dpfr privacyEdit" macro='setPrivacy label:no interactive:yes'></div>
I found it, because some of my plugin spaces, where system-theme stuff is removed caused weird problems, if you create new tiddlers. (private / public) issue ...
There are several macros where we have something similar to
var actPrivateMode = config.options.chkPrivateMode ? "private" : "public";
config.macros.ANYMACRO.defaultWorkspace = tiddlyspace.getCurrentWorkspace(actPrivateMode);
imo .getCurrentWorkspace(mode) isn't the right function to use here. It is very error prone. If you are a new dev, working with TS this is a trap, that may be hard to find.
imo a solution would be to have tiddlyspace.getDefaultWorkspace(), as a new function. All macros (4-5) that are affected should be fixed. So if a new dev looks at TS source will see, how to handle it.
what do others think