Modify

Opened 6 years ago

Closed 3 years ago

#4759 closed enhancement (fixed)

[feature-request] revision handling for submit changes

Reported by: tekknokrat Owned by: hasienda
Priority: high Component: TracFormsPlugin
Severity: normal Keywords: content version
Cc: Trac Release: 0.11

Description

Is there any feature implementation regarding revisioning changes to a formular in timeline/wiki planned?
In stable version I can't find a option to activate this.
For the usecase of having selectboxes for own todolist I can go without but what when you have some editfields with data that could be changed?

Attachments (0)

Change History (9)

comment:1 follow-up: Changed 6 years ago by anonymous

  • Priority changed from normal to high

Also the revisioning of updates should be handled like wiki do this natively.
Otherwise formsplugin can't be used in an environment where several people works on the same document.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 4 years ago by hasienda

  • Keywords content version added
  • Type changed from defect to enhancement

Replying to anonymous:

Also the revisioning of updates should be handled like wiki do this natively.
Otherwise formsplugin can't be used in an environment where several people works on the same document.

Agree. Data is already stored to db table 'tracform_history' as far as I can see, and the switch is to activate is the #! keep_history statement inside the forms header, but we certainly favor a way to access that history via web UI and avoid poking inside the db, where regular users can't get in anyway. :-)

Adding changes to timeline (via a dedicated forms timeline event provider) as mentioned in the report is certainly a different story.

comment:3 Changed 4 years ago by hasienda

  • Owner changed from rharkins to hasienda

Formally taking over ownership after getting maintainership. This is a mid-term goal of mine.

comment:4 Changed 3 years ago by hasienda

  • Status changed from new to assigned

I've further looked into the code, an it looks like I'll arrange for a changes view like in tickets history, maybe even reuse exactly that renderer as time permits. It will surely happen one way or another, since my production application requires such an audit trail too.

comment:5 Changed 3 years ago by hasienda

(In [10079]) TracFormsPlugin: Add basic history browsing capability, refs #3445, #4759 and #8258.

Fix code around TracForms db handling after using tuple for 'src'.
Plugin now contributes to parent resource's context navigation,
db interface is grown by a method for reverse-lookup of forms and
the 'Form' resource is getting extended to provide more information too,
everything needed to establish infrastructure for history browsing.
With the addition of templates we need to extend i18n capabilities as well.
This is the base for later adding form reset and delete/purge functions.

comment:6 Changed 3 years ago by hasienda

(In [10126]) TracFormsPlugin: Introduce a stepwise history reset method, refs #3445 and #4759.

Now we utilize the TracForm history parser for recovering the previous state.
With an obvious but notable limitation: We need recorded form history,
that currently is an optional form command, otherwise fallback to a simple
form reset.

comment:7 Changed 3 years ago by hasienda

(In [10127]) TracFormsPlugin: Make stepwise history reset method available, refs #3445 and #4759.

I've made a decision to not support an single form field reset. So with this
changeset the TracForm reset support is nearly final as far as I consider
it to be necessary, and reasonably usable according to my tests.
But a form reset is a final decision, there is even no confirmation dialog,
so FORM_RESET permission should be granted with care to keep this actions
administrative.
Again: Think before pressing the almighty button(s) - you've been warned.

comment:8 in reply to: ↑ 2 Changed 3 years ago by hasienda

Replying to hasienda:

Adding changes to timeline (via a dedicated forms timeline event provider) as mentioned in the report is certainly a different story.

So I opened #8748 to track this issue independently.

comment:9 Changed 3 years ago by hasienda

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [10143]) TracFormsPlugin: Releasing version 0.3, pushing development to 0.4, closes #3445, #3550, #3741, #4759 and #8258, refs #3388 and #6993.

This is a major release requiring a Trac environment upgrade.

While the parser logic remains unchanged, there is a lot new supplementary
funcionality to make TracForms behave more like the existing Trac core
resources (ticket, wiki, attachment, ...).

This version performs a series of non-trivial db schema changes, that
especially may leave traces of stale forms (i.e. recorded for wiki pages,
that don't exist anymore). So please make sure to read the changelog,
BACKUP your environment(s) before installing this version as usual and check
the new db tables forms, forms_fields and forms_history after upgrading.

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.