TiddlySpaceCloneCommand should use chkPrivateMode #940

Merged
merged 2 commits into from Jul 2, 2012

2 participants

@pmario

Cloning an included tiddler should respect the chkPrivateMode user setting

@cdent

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?

@pmario

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
@pmario

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