2 TracForms in one ticket(s comments) delete each others data

[anonymous]

I have a ticket with comment 1 consists of

{{{
#!TracForm
#! submit_label "Got 'em!"
|| [tf:bla1] || bla1 ||
|| [tf:bla2] || bla2 ||
}}}

and with another comment 2 that consists of

{{{
#!TracForm
#! submit_label "Got 'em too!"
|| [tf:bla3] || bla3 ||
|| [tf:bla4] || bla4 ||
}}}

The bug is that whenever I click on "Got 'em too!" of the second Trac form, all checkboxes of the first Trac form are unchecked again. And also vice versa, whenever I click on the other button "Got 'em!".

You see I cannot use 2 different Trac forms in one ticket. This is bad...

[Steffen Hoffmann]

Procedural comments:

1. Properly escape valid wiki macro and wiki processor input in ticket description and comments, or it could get executed in the trac-hacks.org Trac, what shouldn’t be your intention.
2. Who is anonymous? Care to provide a valid contact for ensuring information flow, please? It tends to become tiresome to speak in a roundabout way and never knowing, if there's still someone listening, you see?

[Steffen Hoffmann]

Summarizing, admittedly a bit weak documentation regarding special use cases like ticket comments (never used it like that, just in ticket description by now), but certainly NOT a code issue. This is a cantwork for using inappropriate markup. Explanation in more details including a hint to relevant documentation follows below.

Replying to anonymous:

I have a ticket with comment 1 consists of

...

and with another comment 2 that consists of

...

The bug is that whenever I click on "Got 'em too!" of the second Trac form, all checkboxes of the first Trac form are unchecked again. And also vice versa, whenever I click on the other button "Got 'em!".

You see I cannot use 2 different Trac forms in one ticket. This is bad...

Not surprising. The plugin code obviously can't distinguish between the two forms without a bit more information.

There are two apartments in your house - creating a real-world example for the situation here. When you commit, you drop a package for no. 4 in ticket street. Well you've to know, that comments are not separate contexts with in the ticket view, of course. Here I assume lacking documentation - a documentation bug, if you insist.

But exactly to prevent/resolve context ambiguity for a TracForms form next to another one we have a the subcontext variable: wiki:TracFormsPlugin/Expert#Multipleformsperresource You'll find, that this enables you to have an arbitrary number for forms within a single Trac resource, if all have unique subcontext variables. The first could go without this variable. This is similar to an implicit default ("here, if no special subcontext has been given").

For the second and more neighbors in the same house you'll need to declare an apartment ID to get the data package shipped to the correct door on request.

I consider that advanced usage, hence the example has been put after the beginner's section. Ok?

May I ask you to reiterate with the information given here and confirm, please?

[falkb]

Replying to hasienda:

Procedural comments:

1. Properly escape valid wiki macro and wiki processor input in ticket description and comments, or it could get executed in the trac-hacks.org Trac, what shouldn’t be your intention.
2. Who is anonymous? Care to provide a valid contact for ensuring information flow, please? It tends to become tiresome to speak in a roundabout way and never knowing, if there's still someone listening, you see?

It's me. Sorry, I was in hurry.

[falkb]

Replying to hasienda:

May I ask you to reiterate with the information given here and confirm, please?

Thanks for you detailed explanation. I'm going to try it tomorrow. Well, the situation was that the test department gave the ticket back with needs_work and put all found issues in 2 Trac forms, since two guys tested and gave their results in their own form. We're quite new to this plugin and I wasn't aware of that limitation.

[falkb]

Yes, using !subcontext solves my problem. Thanks!

[Steffen Hoffmann]

Great. Thank you too for providing encouraging feedback here.