Item8873: Macros don't expand when used in topic preference settings

According to TemplateTopics#Macro_expansion, certain macros used in template topics should be expanded at topic creation time. However, it appears that this isn't the case for macros placed in %META of a template topic.

If, for example, you built a wiki application for blogging, and you needed to restrict editing access to a topic's creator and a group of editors, you might add the following to your template topic's preference settings:

* Set ALLOWTOPICCHANGE = %WIKINAME%, Main.BlogEditorsGroup, Main.AdminGroup

That way, your preference setting is neatly hidden away, and can't be accidentally edited or munged by the WYSIWYG.

Unfortunately, this fails; I've tested all of the macros listed at TemplateTopics#Macro_expansion, and none of them are expanded when new topics are created with the template topic. Bummer.

Steps to reproduce

• Create a new template topic.
• Edit topic preference settings to set access control or other preferences using any of the macros listed at TemplateTopics#Macro_expansion
• Create some new topics with the above template.
• View the topic preference settings for any of the new topics; the macros will not have expanded as the documentation states they should.

-- AaronFuleki - 09 Apr 2010

Do you mean preferences store in meta-data (%META:PREFERENCE) or preferences stored in topic text (* Set ALLOWTOPICRUIN = )?

If it's the former, I could understand it, that's expected behaviour. If it's the latter, then it's a bug.

-- CrawfordCurrie - 17 Apr 2010

I mean things set by clicking "More topic actions..." -> "Edit settings for this topic", which I believe is stored in %META:PREFERENCE blocks.

I don't understand how this would be expected behavior, when macros present in %META:PREFERENCE blocks do appear to expand properly at view time, just not topic creation time (unless I'm wrong - I'll test that to be sure).

Either way, I'd call it a coherence bug, as there's no reason to think macro expansion should behave differently in the preferences area (at least not from the interface, documentation, or common practice). If I'm just missing something on this, feel free to correct me/shut me up

I'd also consider this a real UX flaw, as it doesn't allow wiki app developers any way to hide things they need expanded at topic creation time from end users. When I demoed the blog functionality of our latest app to some users, they were all confused by the big commented-out-hunk-of-stuff in the middle of their new post. It took less than a minute for novice users to mess it up via copy/paste, and thus they started breaking things straight away!

I was able to explain what it was, and they're happily using the app, but I'd like to avoid problems like that completely, where possible.

-- AaronFuleki - 21 Apr 2010

%META:PREFERENCEs are indeed transferred, but are not processed through the engine that expands macros when the new topic is instantiated. I'm not saying this is correct behaviour, just that it's expected behaviour - that's the way whoever coded this stuff made it work. I agree that it's a coherence problem. It's a toss-up whether it should be classed as a bug or a feature request, though, as it has been that way since.... a long time ago. On balance, though, I share your view that it's a bug, so I've confirmed this report. Unit tests and a fix are required.

-- CrawfordCurrie - 22 Apr 2010

Done.

-- CrawfordCurrie - 23 May 2010

backed out the change - it broke the FuncUser and Manage unit tests when it was comited.

-- SvenDowideit - 26 May 2010

Re-un-de-backed it in, and fixed the real cause of the tests failure, and fixed a couple more while I was in there.

-- CrawfordCurrie - 26 May 2010

Re-opening to fix a typo. CDot was faster

-- OlivierRaginel - 26 May 2010