So, how do I do the processing of >activities that can be processed later.

[Jay]

A couple of examples could be very helpful here. I see at least 2 use cases of the bat:

Test case/run tickets, this would be awesome me thinketh!

and to list resultant activities. I was looking to write a workflow/blackmagic based plug to generate master/slave tickets based on a check box type answer when accepting a ticket (user manual update required? Code review Required? Validation Plan Changes?) which would generate blocking tickets. This would be superior in my mind. especially since I can create form templates for common activity "types" bring up the ticket, see what has been done, what hasn't

but how do I, process tickets to identify the ones that have the "required" checked, but the completed not (some may want this as part of the work flow, me, more of an informational) at some point. Say, show me all tickets requiring user manual updates, which don't have user manual updates completed.

[Jay]

Additionally, for the test run use case, the ability to print the form out would be crucial, so it could be put into a project file and signed, again I think this would be awesome!

[Rich Harkins]

Part of this will likely be handled by #3263 (planned for release 0.3).

[Rich Harkins]

Er, make that #3264... ;)

[rupert thurner]

could this replace TestCaseManagementPlugin ?

[Rich Harkins]

See #3282 regarding using TracForm for test cases.

[Jay]

Personally, I see it as a "replacement" for the TestCaseManagmentPlugin. I would actually use it 2 ways for tests. A ticket, could JUST be a form, that is a test suite(maybe a blocking ticket of some large task-set type ticket (i.e. "fix the gui", with 20 issues, and the "test the gui" test ticket with form). A specific instance could additionally have a "testplan" form attached, specific to that issue. (eg. The how to verify tests) I also plan to use this plugin as a "TODO" type checklist, as mentioned for tasks/tickets. The workflow integration might be a nice to have, but in reality, my need is more for the person fixing the issue to think about things like does this affect a test plan? yes, did I update the test plan?, etc.

However, what I am REALLY asking for in this particular ticket, is HOW do I process the form(s), in a useful, TRAC sort of way? (i.e. report/query)

Lets say, for example, I added a form with the simple fields(pseudo syntax follows): tf:checkbox 'Testplan Updates required?' 'completed on/Notes->tf:textbox'

How can I find tickets (lets say "resolved" a custom state) with Testplan Updates Required?=1 and completed on/Notes=null (or whatever, use whatever field types you like) In other words, a ticket the developer said he completed, and the QA guy wants to filter out as "tsk, tsk, you forgot to update the test plan."

btw, this is a great plugin. I just hope I can find a way to extract this key information, ideally so I can print/export/version control the form results. Being greedy, that becomes a solution to about 5 or 6 things I need to find a way to integrate into trac/subversion, all in one nice tidy package.

[anonymous]

So,

no ideas on how to process the content of the forms?

[Rich Harkins]

Apologies for not seeing your reply earlier. It's been an ultra-crazy month.

I'm rolling the concept around a bit and am not sure I completely get it. Are you looking for:

1. A way to query results (definitely something that's in mind but not yet planned as I'm not totally sure how that part of Trac works yet)
2. A way to put results in a common place (supported using the #!page command).

In the case of scenario 2, perhaps something like the following might work for now:

{{{
#!TracForm
#!page tests:all-my-tests

Exception Notes: [tf.input:test1234-notes]

}}}

And then on a summary page:

{{{
#!TracForm
#!page tests:all-my-tests

1234: [tf.input:test1234-notes]
1235: [tf.input:test1235-notes]
1236: [tf.input:test1236-notes]
}}}

But, I'm thinking that's too cumbersome really.

So, unfortunately, I don't have a silver bullet on this one yet. Because of some of the more advanced cases I'm presently refactoring the parsing mechanisms (in a backwards-compatible way) to help make things like this and other calculations smoother. The voting style calculations I'm finding to be too messy in practice so I need to smooth out the details.

In your context, a linkage to search is almost certainly necessary as the upgrades I've got in mind will only help with visual scan searching. That being said, I'll take a look at the indexing processes with the other work soon and hopefully that will fully help the issue.

See ticket #3500 as well and please feel free to comment further on that particular aspect. I'm also going to bump the priority on this one as I see the potential value in using this for testing as well.

Thanks for your patience! Rich

[Steffen Hoffmann]

Replying to yoheeb@gmail.com:

![...] btw, this is a great plugin. I just hope I can find a way to extract this key information, ideally so I can print/export/version control the form results. Being greedy, that becomes a solution to about 5 or 6 things I need to find a way to integrate into trac/subversion, all in one nice tidy package.

I'll provide a quite generic ISearchSource imlementation within few weeks from now, so you may actually just use the regular ​TracSearch for this, i.e. with a search term like Required?=1. Not sure about quickjump for the new form resource, but at least I've already managed to find arbitrary text input in input fields and textareas. Checkboxes are more of a problem, since most of their standard value representation as string ('0', '1', 'on') is below the min-3-chars threshold of the TracSearch. This could be only circumvented by actually joining key:value pairs literally before matching them against search terms.

Anyway, join in please, if you still need this.

[Steffen Hoffmann]

TracForms 0.3 is out, with basic ​t:TracSearch support included.

Development of a TicketQuery-like FormQuery functionality is tracked in #8749. Is this what you want(ed)? BTW, just to mention I don't care about Trac < 0.11 anymore.

[Steffen Hoffmann]

Neither do you care nor can I do something, as long as requirements are blurred. "Replacement for plugin xy" isn't an important objective to me either.