On Thursday, February 6, 2014 8:58:57 AM UTC-8, Soha wrote:
>
> Hi guys,
>
> I am facing a new issue and I suspect this has surely something to do with
> the Workflow
>
> I am trying to generate a report where I need to display the below columns
> in the report.
>
> Ticket
> Summary
> Component
> Version
> Type
> Reporter
> Owner
> Status
> Created
>
> The problem is with the status display {The values for the status field in
> the trac ticket are : 'Submitted', 'Assigned', 'Under Review', 'Closed',
> 'Fixed', 'Not a Bug', 'Fix Confirmed'
>
>From the image you've posted, it looks like you've added a custom field
named "Status". Is that correct?
The values displayed in your column are not actions, they are ticket
"states" (or "statuses"). When you define a workflow action, you also
define the states / statuses that the action will transition between:
action1 = state1, state2, state3 -> state4
So when you invoke action1 and the ticket is in state1, it will transition
to state4. The state values are stored in a ticket table column named
"status". You've mentioned statuses: 'Submitted', 'Assigned', 'Under
Review', 'Closed', 'Fixed', 'Not a Bug', 'Fix Confirmed'. If you want those
to be associated with ticket states, you'll need to define workflow actions
such as:
submit = new -> Submitted
assign = Submitted -> Assigned
If you'd like these statuses that you've defined to be independent of the
workflow, then you'll need to query the ticket_custom table. The SQL for
your report queries the status field in the ticket table, which will show
the current "state" or "status" of the ticket.
http://trac.edgewall.org/wiki/TracTicketsCustomFields#ReportsInvolvingCustomFields
I suspect you want to make those statuses part of the workflow, and that
you are just struggling with how to setup the workflow. The Workflow macro
can be a big help when trying to define your workflow:
http://trac.edgewall.org/wiki/WikiMacros#Workflow-macro
> But it is displaying the actions associated with the workflow or only
> ‘new’ status when submitted.
>
> Like example :
>
>
>
> When you submit a new ticket the status will be 'Submitted' in the Trac
> ticket. When you try to modify the ticket it gives an action to select as
> below :
>
>
>
> Likewise when you change the Status to the next option like Assigned it
> will give the assign action; under review gives as test. So when you modify
> the ticket and select the option it will give the next action in the
> workflow when you try to modify it. I am not sure how this wholething is
> inter connected. All I need to show in the report is just the status values
> “’Submitted', 'Assigned', 'Under Review', 'Closed', 'Fixed', 'Not a Bug',
> 'Fix Confirmed' only. But somehow it shows only displays the status as new
> if the ticket is submitted else the action name like
> ‘assign_severity_and_analyze’ so on.. To reflect the closed status I need
> to make multiple modifications which includes selecting and submitting all
> the actions defined in the workflow.
>
> Please help me understand why the status is populating the actions and
> everytime I need to select the action before going to next status. So
> please let me know if this is how it is supposed to react.
>
> My Query :
>
> SELECT p.value AS __color__,
> version AS __group__,
> id AS ticket, summary, component, version, t.type AS type, t.reporter
> AS reporter,
> owner, status,
> time AS created,
> changetime AS _changetime, description AS _description
> FROM ticket t
> LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
> WHERE status <> 'Submitted'
> ORDER BY (version IS NULL),version, CAST(p.value AS integer), t.type,
> time
>
> Thank You in advance !
>
>
>
>
>
>
>
>
>
>
>
> On Thursday, February 6, 2014 10:55:44 AM UTC-5, Ethan Jucovy wrote:
>>
>> On Thu, Feb 6, 2014 at 10:36 AM, Ethan Jucovy <[email protected]>wrote:
>>
>>> On Thu, Feb 6, 2014 at 9:32 AM, Soha <[email protected]> wrote:
>>>
>>>> Hi,
>>>>
>>>> Looks like I have given the wrong workflow. Please consider the below
>>>> one :
>>>>
>>>> analyze = new_ticket -> assign_severity_and_analyze
>>>> analyze.default = 999
>>>> analyze.operation = set_owner_to_self
>>>> analyze.permissions = TICKET_CREATE
>>>> assign = assign_severity_and_analyze -> triage_and_assignment
>>>> assign.default = 996
>>>> assign.operation = set_owner
>>>> assign.permission = TICKET_MODIFY
>>>> close = user_test -> closed
>>>> close.default = 994
>>>> close.operation = set_owner
>>>> close.permissions = TICKET_CREATE
>>>> fix = triage_and_assignment -> fix
>>>> fix.default = 995
>>>> fix.operation = set_owner
>>>> fix.permissions = TICKET_MODIFY
>>>> leave = closed -> *
>>>>
>>>> leave.default = 1000
>>>> leave.operations = leave_status
>>>> reopen = unit_test,user_test -> triage_and_assignment
>>>> reopen.default = 992
>>>> reopen.operation = del_resolution
>>>> reopen.permissions = TICKET_CREATE
>>>> resolved = triage_and_assignment -> closed
>>>> resolved.default = 993
>>>> resolved.operation = set_resolution
>>>> resolved.permissions = TICKET_MODIFY
>>>> test = fix -> unit_test
>>>> test.default = 997
>>>> test.operation = set_owner
>>>> test.permissions = TICKET_MODIFY
>>>> uat = unit_test -> user_test
>>>> uat.default = 998
>>>> uat.operation = set_owner
>>>> uat.permissions = TICKET_MODIFY
>>>>
>>>
>>> The 'Warning : The action view is not available".' message would appear
>>> if you POST a ticket form (modifying the ticket and/or leaving a comment)
>>> that doesn't contain an "action" parameter. But I'm not sure why that
>>> would be happening if you're using Trac's built in user interface.
>>>
>>> One problem: you have "analyze = new_ticket ->
>>> assign_severity_and_analyze". But "new_ticket" isn't a new ticket's
>>> starting state -- that should be "new". Right now you have no workflow
>>> actions attached to the "new" state, which all newly created tickets start
>>> out in. So, any time you're trying to leave a comment or modify the
>>> ticket, it seems like there are no valid actions that can be taken.
>>>
>>> There seems to be more going on here -- I think
>>> ConfigurableTicketWorkflow is supposed to provide a "_reset" action for
>>> cases like this, which should be submitted in the POST request instead of
>>> nothing being posted. Unless you have other plugins installed which are
>>> changing the behavior of the ticket modify form.
>>>
>>
>> For future reference: I can reproduce the problem using the above
>> workflow configuration on a new trac environment. I'm going to look into
>> this a bit to figure out why "_reset" isn't kicking in. I'll file a core
>> ticket if it seems appropriate once I understand a bit more about what's
>> going on.
>>
>> -Ethan
>>
>
--
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/groups/opt_out.
