Codestriker::Action::SubmitNewTopic->process should
return the unique topic id or -1 if the request failed.
This would allow other tools to call in to codestriker
to create topics and return some unique cookie that
they can use to further define the topic. For
instance, I could have our existing software
development web site (which tracks CSCIs, CSCs, and
CSUs) create other tables in its own database which
correlate the CSCI/CSC/CSU/whatever to the created peer
review created in codestriker.
<example>
Imagine a separate set of cgi scripts used to maintain
software development process metrics on multiple
projects. Each project consists of a CSCI
(application) which is composed of modules and finally
units. The cgi scripts allow creation, modification,
and deletion of these project entities. We also want
to modify the scripts to add and show peer reviews for
the units but we need to be able to create the topics
in Codestriker so that they may be queried based on our
own set of attributes (CSCI, CSC, CSU, etc). Since
there is no current way to define user attributes for
peer reviews, I think the least intrusive way of
allowing this is to have the codestriker modules
responsible for creating the topic return the unique
topicid. So for instance our cgi-script to submit a
new topic for a CSU would simply call
SubmitNewTopic->process() and use the return value to
add a row to our CSU peer review table. The CSU peer
review table might be defined with the CSU unit name,
CSC name, CSCI name, peer review type, and the topic id.
</example>
Submitted anonymously by deischen@gdeb.com
Logged In: YES
user_id=208928
I think you are better off using the
bin/CodestrikerClient.pm module, which is used for creating
topics from scripts. At the moment, it can be used as a
part of a CVS post-commit script, but could be used for
anywhere.
The intention is if software needs to create a topic, this
module provides the necessary.
You may need to modify it slightly to return the topicid
rather than what it is at the moment.