Error if submitted in a wiki page with version specified

[JaeWook Choi]

When a submission of TracForm occurs in a specific version of wiki page, it causes HTTP 500 error. Especially a newly created wiki page will be redirected to version 1 after the creation of the wiki page and caused HTTP 500 error.

For example, submitting form data in wiki/SandBox/TestForm?version=1 causes HTTP 500 error while it works fine in wiki/SandBox/TestForm

[Steffen Hoffmann]

Sorry for late response. I took over maintainership just yesterday, and trying to catch up.

How do you expect TracFormsPlugin to work with in (older) revisions of wiki pages?

I'd suggest trying to

1. block it at all (soon), and later maybe trying to
2. restore older form values related to that wiki page revision.

Second point is largely in shadows for me by now. It might be hard (involving db table changes/extension or not, I don't know.

[Steffen Hoffmann]

Still relevant?

We may have a version-aware Form object/Trac resource soon, not sure about connecting wiki/ticket revisions and form revisions. But it would require at least an additional column to store such an (parent) version hint.

[Steffen Hoffmann]

After more fiddling around with code when introducing the 'form' resource for TracForms recently I conclude, that this can hardly work. I even find it unreasonable to put much effort in here, while other reasonable requests would have to wait, i.e. see #3445, #5667.

What are new revisions of form content for historic forms meant to represent? I argue, that any attempt towards serving such functionality is bound to screw the whole concept of current Trac's revisions: There is always a straight, unbranched line of revisions per resource. Updating content from within a historic form version means branching from that point.

Theses:

• Easiest would be to aim at clearly blocking form update requests sent from older revisions.
• Best would be to branch revisions like in modern VCS. Older form revisions would present corresponding older form content to start editing from there automagicly. In theory it should be possible to have one history per form (parent) revision. But how to proceed after a form (parent) change? right now I can't think of a real-world use case, that would strictly require such a concept. The previous "easy" way looks still sane and simple.

All I'll do within a reasonable time frame is following #4759 for now.