Item6032: moving a topic across webs modifies its dataforms

How to reproduce:

1. in TestWeb1 (or whatever you cal lit), create a form ContactForm with a formfield CompanyName
2. create a topic CompanyName (not sure if that step is needed)
3. create a topic and attach this form to it
4. move it to another web TestWeb2
5. check out the data of the form after it has been moved using ?raw=all
6. your formfield ContactForm has been renamed to TestWeb1.ContactForm and thus has destroyed any code (e.g. $meta->get('FIELD', 'CompanyName') ) that relied on it to be called ContactForm and not TestWeb1.ContactForm .

How do we resolve this? Is it okay to never ever rewrite formfield names (and titles)? When would you expect formfield names to be renamed the same way normal WikiWords are?

-- MichaelDaum - 30 Sep 2008

years ago, I started to use fully qualified names for formfields - as in, always Web dot WIkiName for exactly this reason.

None the less thou, I found it necessary to make moves and renames affect form meta data (as for WikiWord renames) - as I found myself moving form definition topics (after they had been used for a while) to a separate web.

-- SvenDowideit - 05 Oct 2008

This is a difficult call, as the form name is also a wikiword. Further, it's a wikiword that may be used to get - for example - options for a select. Therefore when you move the form to a different web, the topic reference must change.

In the case of the specific example you give, I'd suggest that the solution lies with the code that looks up the form field, and not the formfield itself.

Either way this has been the case for a long time, and cannot be classed as a release blocker. Confirmed as "Normal".

-- CrawfordCurrie - 03 Nov 2008

This bug is so severe for me that I added specific code to the ClassificationPlugin to revert changes in the formfield names made by a move operation.

-- MichaelDaum - 13 Nov 2008 - 08:53

This bug has been reported long time ago and it still bites me every day. I raised it to urgent again to give it another spin. Note, that rewriting wiki words in meta data not only affects the form name but also pretty much anything stored in meta data.

Let me elaborate further:

• there's a topic SourceWeb.MyTopic that has got the formfield TopicType with the value ClassifiedTopic
• there is a topic in the SourceWeb called ClassifiedTopic and the formfield value of SourceWeb.MyTopic links to it within the SourceWeb ... as expected.
• note, the data form isn't displayed. so the fact that the WikiWord might link to an existing topic in the web is negligible.
• there is also a topic in the TargetWeb called ClassifiedTopic (means, both webs participate in the knowledge management application)
• now, when I move the MyTopic from SourceWeb to TargetWeb the WikiWords within the data form are rewritten to point back to the original location, that is ... the formfield value of TopicType of the new TargetWeb.MyTopic becomes SourceWeb.ClassifiedTopic even though I want it to be the same as it was: just stay ClassifiedTopic.
• there is a specific afterSaveHandler() in ClassificationPlugin that fixes the TopicType field again .... bah

I am not sure what the best way is to resolve this issue as there are use cases for both (1) rewrite and (2) don't rewrite formfield values during move/rename. Any ideas?

-- MichaelDaum - 10 Dec 2009

In my case, the web is a namespace/context area and the form field name is a topic that represents a concept within that context which either won't exist or won't mean the same thing in the target web. So the existing behaviour actually works as I need it to.

• I see. Well, would you move topics between those webs at all, i.e. given that prerequisites for the moved topic to make "sense" in the new web are not fulfilled? -- MD
• Well, I don't think we have moved form topics to other webs, no. But we do have a need for building forms that use term topics outside of the current web. The application framework allows groups to build these "term topics" as a sort of vocabulary; then a different group of users cherry-pick the terms they need from a variety of contexts/namespaces to build new forms ("profiles"); then a different group again are able to do data entry using those forms. The idea is that the profile (form) builders should be able to build 90% of their form using existing well-defined terms, and only create new terms of their own within their own specific context only if they truly need to. -- PH

What if: Fully qualified TopicName formfields retained the existing behaviour; JustATopicName as a formfield name doesn't get rewritten?

A less violent solution would probably be to add a new attribute (we already have M and H: how about NR? No-Rewrite)

I think 1.0.9 is actually overdue, it would be nice if we could assign this to a later release.

-- PaulHarvey - 10 Dec 2009

Michael, just to be sure I'm understanding you: You want the move process to leave the form fields untouched, even if the form name is updated to point to the original web?

-- RafaelAlvarez - 10 Dec 2009

Rafael, I'd prefer the move process not to touch the name nor the value attribute of a meta data object as both has high potential to break wiki apps. Sorry if I was unclear.

-- MichaelDaum - 11 Dec 2009

Hi Michael, I don't deny that the current behaviour is probably detrimental to the majority of dataform apps out there.

If we are to fix this thing I would still like access to the existing behaviour. The web that the term topic lives in (or rather, the link that fully identifies the concept) is important information to me and I don't want that to be lost during a move.

Hopefully this can be achieved by implementing an additional formfield attribute.

-- PaulHarvey - 12 Dec 2009

I was just thinking about this in the context of an dataform application I just wrote. It would be a disaster if the formfield was not renamed when the topic moved; I rely on the renaming of the formfield to access select options, without reproducing those options in every target web. So this is not so clear cut. the more I think about, the more convinced I am that the current behaviour is the expected behaviour, and what Michael is proposing is counter-intuitive for most people.

I changed the wording of the summary from "destroys" to "modifies" because this modification is actually beneficial to many dataform apps.

Given that the current behaviour cannot (IMHO) be classed as a bug, we are left with looking at this from Michael's perspective. He needs to be able to "protect" field names and values from rename. Here are a few ideas:

1. Add an interactive option to suppress reference renaming during renaming of a form topic
2. Add TML to create suppression regions e.g. ...
3. Add %META that tells the rename code how to handle formfield references in the given topic
4. Add one or more preferences to control renaming behaviour
5. (12:55:25) pharvey: Regarding http://foswiki.org/Tasks/Item6032, what about adding a new formfield attribute other than M and H?

-- CrawfordCurrie - 12 Dec 2009

I agree with Crawford. Changing the spec will make some happy and others not happy.

We have had several similar bug reports before and we have zig-zagged with bugs that changed too much when we rename and others that changed too little.

Better keep the spec as is - and find a new feature type solution to Michaels fully valid use case. Challenge is a solution that does not score too high on the NerdoMeter.

I guess it is time to go into a Feature proposal phase and come with some solutions. I am sure a good proposal can reach consensus. I am putting this in No Action but please reopen when we have a feature proposal passed.

-- KennethLavrsen - 13 Dec 2009