current ticket type not respected by form when modifying ticket

[dkim...@gmail.com]

Hi,

We recently upgraded to the latest trac and agilo versions and have observed a rather annoying bug with the ticket type since. 

When modifying a ticket, it does not pre-select the ticket's type from the dropdown (even though it's shown clearly in the title) so when submit it changes the ticket type to whatever the first entry was. Tested this on a stock trac+agilo project with no upgraded data or customizations and observed the issue. The stock trac (1.0.8) without agilo, previous versions (trac 0.12 + agilo 0.9.9) and your live demo (1.3.14-PRO) are able to detect and select the appropriate type in the combobox.

Steps to reproduce

prereqs:

* reorder Ticket Types (if not already): Task, Bug, Story, Requirement

* remove stock "defect" & "enhancement" Ticket Types (or move to bottom, doesn't matter)

1. Create a new Bug ticket

2. Open the new ticket and make a change

3. Click Submit Changes

Expected:

Ticket Type selected is Bug, changes made and ticket type remains Bug

Actual:

Ticket Type selected is Task, changes saved but ticket is now a Task

Observations:

I'm a developer and was curious so I dug around in the python code for a bit and got as far as getting it to log the data it received back from the database and the dictionary used to populate the fields. It appears to always have 'defect' set for the field value even though the SQL returns the correct type and the page header is correct...perhaps the issue is in that area or it's getting lost in translation?

Let me know if anything else is needed to resolve the issue.

Versions:

python 2.6

Trac-1.0.8

agilo-0.9.14 (not pro)

Thanks,

Deb

[Claudio Di Cosmo]

Hi Deb,

Unfortunately, for now, our agilo for Trac is tested until version 1.0.2. This version is not affected by this issue. 

I have created a ticket that for the problem (https://agilo.agilofortrac.com/ticket/1399). 

Soon we will work on the alignment of the newer version of Trac and we will make sure to address it.

Sorry for the inconvenience and thank you for pointing us the issue, 

Have a nice day,

Claudio Di Cosmo
Software Engineer
Agilo Software GmbH
Gruenberger Str. 54
10245 Berlin, Germany

claudio...@agilosoftware.com
http://www.agilosoftware.com

Follow us on twitter: http://twitter.com/agiloforscrum, http://twitter.com/agilofortrac

Amtsgericht Charlottenburg: HRB 127146
CEO Marion Eickmann, Andrea Tomasini

[dkim...@gmail.com]

haven't found the root cause, but I did find a workaround that I'd like to share with others until it is fixed officially. I'm sure there's a simpler way to do it, but this worked for our implementation. Basically mimic'd the older trac way of filling in the type but used the ticket.get_alias(ticket.get_type) to figure out which should be selected.

I suggest verifying in your dev environment before deploying to prod as it may need some tweaking if you've made your own modifications to the template, but it should get you started.

1. modified the agilo/ticket/templates/agilo_ticket_edit.html replacing the "otherwise" block for display of type field in current trac versions (code below)

2. restart apache 

3. reload ticket and it should respect the ticket's type

--begin codeblock

            <py:otherwise>
                <!--
                CUSTOM 10/28/2015:
                select the correct type based on ticket alias rather than the type (Bug vs bug) since somehow all the options are the alias
                <select id="field-type" name="field_type">
                    ${select("*|text()")}
                </select>
                -->
                <py:for each="field in fields">
                    <py:if test="field.name == 'type' and field.type == 'select'">
                        <py:with vars="value = ticket.get_alias(ticket.get_type())">
                            <select id="field-${field.name}" name="field_${field.name}">
                               <option py:if="field.optional"></option>
                               <option py:for="option in field.options"
                                       selected="${value == option or None}"
                                       py:content="option"></option>
                               <optgroup py:for="optgroup in field.optgroups"
                                         py:if="optgroup.options"
                                         label="${optgroup.label}">
                                 <option py:for="option in optgroup.options"
                                         selected="${value == option or None}"
                                         py:content="option"></option>
                               </optgroup>
                            </select>
                        </py:with>
                    </py:if>
                </py:for>
            </py:otherwise>

--end codeblock

[Taylor Brown]

Hello,

I'm a fairly new user. I have Trac 1.0.2, Agilo 0.9.14 (free), Python 2.7, CentOS 7. I'm running the standalone version of Trac. I also see this issue ("defect" is the default ticket type), and it makes Trac almost unusable. Every time we want to modify a ticket's description, sprint, story points, etc., it will fail if the type is "defect" instead of the proper type. It was confusing to figure out what the issue was in the first place, and the workaround of having everyone manually set the correct type for each change made us consider using a different tool entirely. That being said, big thanks to the user in this thread who posted the python workaround to the agilo_ticket_edit.html file. So far that appears to have resolved this issue. I just wanted to provide my feedback here so that the Agilo team knows this is a major usability issue.

Thanks,

Taylor

[Subodh Harmalkar]

I am a newbie as well. And I completely concur with Deb and Taylor's comments above. This resolved a major stumbling block for us to use Agilo. Thanks Deb for the fix. I hope Agilo's team will pick it up.

[Claudio Di Cosmo]

Hi everybody,

> On 14 Nov 2015, at 20:14, Subodh Harmalkar <subodh.h...@jhuapl.edu> wrote:
>
> I am a newbie as well. And I completely concur with Deb and Taylor's comments above. This resolved a major stumbling block for us to use Agilo. Thanks Deb for the fix. I hope Agilo's team will pick it up.

We really apologize for the inconvenience.
We will work as soon as possible on Agilo for Trac. Our main target for the next releases will be to extend the support to the latest version of Trac and to redesign the interface in order to improve usability and your experience in general as long with fixing bugs that we have collected.
Thank you Deb for the fix suggestions, we will consider it for the fix of this bug.

@Taylor: until now we have experienced this issue just on versions of Trac higher than 1.0.2. Can you please send me the /about page content, in order to collect more data about it?

Thank you very much for your understanding,

Cheers,