Modify

Opened 6 years ago

Closed 3 years ago

#3831 closed defect (wontfix)

Error if submitted in a wiki page with version specified

Reported by: butterflow Owned by: hasienda
Priority: normal Component: TracFormsPlugin
Severity: normal Keywords: wiki revision historic form data
Cc: butterflow Trac Release: 0.11

Description

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

Attachments (0)

Change History (3)

comment:1 Changed 4 years ago by hasienda

  • Keywords wiki revision historic form data added
  • Owner changed from rharkins to hasienda

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.

comment:2 Changed 3 years ago by hasienda

  • Summary changed from Error if submiited in a wiki page with version specified to Error if submitted in a wiki page with version specified

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.

comment:3 Changed 3 years ago by hasienda

  • Resolution set to wontfix
  • Status changed from new to closed

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.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.