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

On Wednesday, September 9, 2015 at 2:13:53 AM UTC-5, Claudio Di Cosmo wrote:
>
> Hi Deb,
>
> On 7 Sep 2015, at 18:34, [email protected] <javascript:> wrote:
>
> 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?
>
>
> 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
>
> [email protected] <javascript:>
> 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
>
>
>
>

-- 
-- 
Follow Agilo on Twitter: http://twitter.com/agilofortrac
Please support us by reviewing and voting on: 
http://userstories.com/products/8-agilo-for-scrum 
http://ohloh.net/p/agilo-trac
http://freshmeat.net/projects/agiloforscrum

You have received this message because you are subscribed to
the "Agilo for Trac" Google Group. This group is focused on
supporting Agilo for Trac users and is moderated by
Agilo Software GmbH <http://www.agilosoftware.com>.

To post to this group, send email to [email protected]
To unsubscribe from this group, send an email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/agilo

--- 
You received this message because you are subscribed to the Google Groups 
"Agilo for Trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to