Opened 15 years ago
Last modified 8 years ago
#5353 new enhancement
Transform input text to static text on submit
Reported by: | Ryan J Ollos | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | TracFormsPlugin |
Severity: | normal | Keywords: | database schema transform static wiki markup |
Cc: | Trac Release: | 0.11 |
Description
I'd like to generate forms that can be filled out, and once the information is submitted the data is stored statically, meaning another user cannot come along and change an entry.
The idea I had was to use an input box, and have it change to read only or static text after submit.
It would be nice if the number of columns adjusted to fit the amount of text entered as well.
Finally, if there was a way to delete rows from the form, as addressed in ticket #3445, that would be nice as well. Particularly if this feature could be restricted to someone with, say, FORM_MODIFY permissions.
Attachments (0)
Change History (3)
comment:1 Changed 14 years ago by
Keywords: | database schema transform static wiki markup added |
---|---|
Owner: | changed from Rich Harkins to Steffen Hoffmann |
comment:2 Changed 13 years ago by
(In [11283]) TracFormsPlugin: Add optional write protection to input fields, refs #3264, #5353, #8715 and #9640.
A new keyword argument '-mode', for now exclusive to tf.input and tf.textarea, with value to choose from the following list:
- ro - input blocked, like static text, but in non-editable form field
- rd - same as 'ro', but don't display stored value but default instead
- rw - regular input behavior at all times (default)
- once - initially 'rw', but blocked ('ro') after first form submission
It's an optional argument, retaining full backwards-compatibility
with existing field definitions by choosing -mode=rw
as implicit default.
comment:3 Changed 8 years ago by
Owner: | Steffen Hoffmann deleted |
---|
We'll have permissions soon here.
The initial application will be to restrict form commit. A TracForm > static WikiMarkup converter sounds like a nifty feature, if we could arrange for saving a new wiki page revision directly out of TracForms, right?
On a related topic I'm just thinking how to find and handle obsoleted TracForm field content, since arbitrary changes happen to TracForms regarding variable name changes, field addition/removal, etc. Currently all saved values are retained, at least until next form commit. I.e. a similar problem doesn't exist with TicketCustomFields, since that fields are stored one-by-one, not as a serialized object like TracForms does with it's fields.
I'm more and more convinced, that this missing normalization is a TracForms db schema design flaw, and field values should rather go into the
forms_fields
db table alongside with form field names and other per-field information in - just as Trac does for custom ticket fields (in db tableticket_custom
).