TiddlySpaceCloneCommand should use chkPrivateMode #940

merged 2 commits into from Jul 2, 2012

2 participants


Cloning an included tiddler should respect the chkPrivateMode user setting


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 ...

@cdent cdent merged commit b0e72a7 into TiddlySpace:master Jul 2, 2012

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
@fnd @bengillies

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment