I need all changes to the form, not only the last change to a form element

Replying to falkb:

I noticed the history is implemented to keep only the last change of each form element. Is this true?

It depends on the options set for the individual form.

Do you plan to implement the full history of changes to the form? How difficult is it do implement it? What is your opinion? It's essential here to have the full history of changes.

Done, works for me. Well, back in 2011 it took me some weeks to figure out existing back-end support and do a suitable web-UI visualization.

After being surprised about your report today I've noticed, that it has been a documentation bug, because TracForms is actually capable of recording the full commit history by setting option keep_history. This is documented now in version 16 of TracFormsPlugin/Syntax. Not much I could due beyond it, couldn't I?

Thank you for taking care. Please re-open, if you require more.

Now the beginner page of my feature walk-through has it too, actually a missing, planned content in there.

This is really a big Pro for TracFormsPlugin. Having no full history is a real killer criterion for us. As you may have seen that is why I already had a look at WikiFormsPlugin. It's also very well programmed. It's very pity that doubled work is wasted in 2 plugins although they actually want to do the same.

Well, the second question here was, if it's possible to have email notification on changes to the form controls. If several people are involved in the ticket form, changes to the form controls should notify the current owner, CC and reporter. It's not clear to me, if that is possible with TracFormsPlugin.

Furthermore, people here checked the current Trac form changelog, but didn't like it very much. Looks a bit too technical and cryptic for non-programmers, and the internal tf IDs confuse them much, as well as there is no order by changetime.

Replying to falkb:

This is really a big Pro for TracFormsPlugin. Having no full history is a real killer criterion for us. As you may have seen that is why I already had a look at WikiFormsPlugin. It's also very well programmed. It's very pity that doubled work is wasted in 2 plugins although they actually want to do the same.

I see. I had similar feelings when I discovered about WikiFormsPlugin. But joined effort was never an option. IIRC it TracFormsPlugin was first, but eventually fall behind due to lack of maintenance. Then WikiFormsPlugin went into the market. Again it was a great start, even some features that are still not available for TracFormsPlugin. But then the author seemingly went away. And while the GPL license ensured true freedom of the published code, due to its intended viral effect it was prohibitive to merge strong aspects of WikiFormsPlugin into TracFormsPlugin.

So I felt doomed, only way has been to push development because I needed a better forms solutions than what had been available at that time. It was a rather lonely way, and even after reaching decent web-UI support I received almost no contributions from other developers or users. Anyway, I see interest behind your worries, so this is a chance to make it an even better solution.

Well, the second question here was, if it's possible to have email notification on changes to the form controls. If several people are involved in the ticket form, changes to the form controls should notify the current owner, CC and reporter. It's not clear to me, if that is possible with TracFormsPlugin.

I translate: A form change should trigger a ticket change notification, even if no change happened to the ticket (description/comment) wiki markup. No this is neither implemented nor investigated in detail yet. A dedicated enhancement ticket with requirements as detailed as possible would help to tell you more about the chance for make it happen. A quick hack seems pretty much possible, but coming back from plugins like AcctMgr or TagsPlugin I've raised my standards of what I consider satisfying code.

First and foremost TracFormsPlugin will need unit testing, and further normalization of the db schema is a strong mid-term objective.

Furthermore, people here checked the current Trac form changelog, but didn't like it very much. Looks a bit too technical and cryptic for non-programmers, and the internal tf IDs confuse them much, as well as there is no order by changetime.

Hm, at least there is one to improve. Honestly, I did all the web-UI stuff without neither lovers nor haters yet. "A bit too..." sounds like "at least a good start".

Recently I've got a ticket or two about the web-UI, so it's about time to work on it again. I.e. sort order by changetime has been requested in #10614, and you should follow-up over there as required.

Finally about IDs, that's entirely up to the forms creator. I've done a lot of 'cryptic' stuff, sure, but providing self-explaining IDs in almost natural, intuitive language is possible as well, and I've received very encouraging critics especially about this aspect for a recent from design of mine. So I suggest, form creator's imagination and skills matter. But the mailing-list is a much better fit for topics like that, if you like to go into details; very off-topic for a development ticket.

Replying to hasienda:

... Anyway, I see interest behind your worries, so this is a chance to make it an even better solution.

The problem as always is that I've actually got no time beside my actual work. That is why I usually just send in one-liner. ;)

I translate: A form change should trigger a ticket change notification, even if no change happened to the ticket (description/comment) wiki markup. ... A dedicated enhancement ticket with requirements as detailed as possible would help to tell you more about the chance for make it happen.

see #10787

Furthermore, people here checked the current Trac form changelog... a bit too technical and cryptic for non-programmers

Finally about IDs, that's entirely up to the forms creator...

yes, but for example, a tf element here is [tf.textarea:A17_Grund_der_Änderung '' 40 3] and its changelog entry should be "A.17. Grund der Änderung", pretty for reading with spaces and dots so to speak, but it's not possible since the syntax of tf doesn't allow "" around IDs. And although it seems it works I'm also not sure about umlauts.