You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Antony Semonella <as...@gmail.com> on 2013/12/08 15:31:31 UTC
Re: [Apache Bloodhound] #617: Switching from QCT to full create
ticket page loses field values
Hello all,
The following patch will fix #617:
https://issues.apache.org/bloodhound/attachment/ticket/617/preserve_qct_fields.diff
Cheers,
Antony
On 8 December 2013 14:29, Apache Bloodhound <de...@bloodhound.apache.org> wrote:
> #617: Switching from QCT to full create ticket page loses field values
> ------------------------+---------------------------
> Reporter: mudri | Owner: antony
> Type: defect | Status: needinfo(new)
> Priority: major | Milestone:
> Component: ui design | Version:
> Resolution: | Keywords:
> ------------------------+---------------------------
>
> Comment (by antony):
>
> The patch [attachment:preserve_qct_fields.diff] will preserve summary and
> description values when "More fields' is clicked.
>
> --
> Ticket URL: <https://issues.apache.org/bloodhound/ticket/617#comment:5>
> Apache Bloodhound <https://issues.apache.org/bloodhound/>
> The Apache Bloodhound issue tracker
Re: [Apache Bloodhound] #617: Switching from QCT to full create
ticket page loses field values
Posted by Ryan Ollos <ry...@wandisco.com>.
On Mon, Dec 9, 2013 at 12:55 AM, Antony Semonella <as...@gmail.com>wrote:
> Hello Ryan,
>
> Thanks for looking at this, I've added a new patch to deal with:
Thanks! More good progress.
> > * Forwarding the values of all select fields in the form
>
> See:
>
> https://issues.apache.org/bloodhound/attachment/ticket/617/preserve_qct_fields_all.diff
>
> I will look at point 2 next to ensure a ticket is created at the
> correct path according to the Product selection.
>
> As a note, the QCT form displays "Version" and "Type" fields when
> accessed from a page that is a child of /main/products/ but does not
> when accessed as a child of /main/x.
We tend to refer to these as "global scope" and "product scope", which are
good terms to keep in mind to aid discussion.
> I'm I correct in assuming this is
> correct behavior as "Version" and "Type" field values are product
> specific?
>
Yeah, I believe it is intended that "Version" and "Type" are only displayed
when at product scope. I vaguely remember a discussion in which it was
suggested that Version and Type should be displayed when at global scope,
but their values should update based on the currently selected product.
(Another good feature would be to disabled the fields when at global scope
until a product has been selected.) Therefore, it may be that Version and
Type aren't currently displayed when at global scope simply because the
necessarily-complex code hasn't been written yet. That can be dealt with
later though after we fix the more fundamental problems with the QCT.
> If so, is the "Product" field redundant on the QCT form when accessed
> from /main/products/x?
>
I think it is not redundant because one may want to create a ticket for
product2 when in the scope of product1. I'll plan to push my changes in
#304 today, which fixes some related issues:
https://issues.apache.org/bloodhound/ticket/304
There is an option `[ticket] quick_create_fields` which allows the
administrator to define the fields that are presented in the QCT form. With
that in mind, we'll need grab whatever fields are present in the form and
forward the values, meaning we won't be able to expect `field_type` and
`field_version` to be the only select fields in the form.
So as you can see it is fairly complex and there are a lot of little issues
to solve, but great work so far!
Please note preserve_qct_fields_all.diff does not appear to work for
> QCT forms outside main/products/some_chlid . I'm currently looking
> into this.
>
> Cheers,
>
> Antony
Re: [Apache Bloodhound] #617: Switching from QCT to full create
ticket page loses field values
Posted by Antony Semonella <as...@gmail.com>.
Hello Ryan,
Thanks for looking at this, I've added a new patch to deal with:
> * Forwarding the values of all select fields in the form
See:
https://issues.apache.org/bloodhound/attachment/ticket/617/preserve_qct_fields_all.diff
I will look at point 2 next to ensure a ticket is created at the
correct path according to the Product selection.
As a note, the QCT form displays "Version" and "Type" fields when
accessed from a page that is a child of /main/products/ but does not
when accessed as a child of /main/x. I'm I correct in assuming this is
correct behavior as "Version" and "Type" field values are product
specific?
If so, is the "Product" field redundant on the QCT form when accessed
from /main/products/x?
Please note preserve_qct_fields_all.diff does not appear to work for
QCT forms outside main/products/some_chlid . I'm currently looking
into this.
Cheers,
Antony
On 9 December 2013 06:56, Ryan Ollos <ry...@wandisco.com> wrote:
> On Sun, Dec 8, 2013 at 6:31 AM, Antony Semonella <as...@gmail.com>wrote:
>
>> Hello all,
>>
>> The following patch will fix #617:
>>
>>
>> https://issues.apache.org/bloodhound/attachment/ticket/617/preserve_qct_fields.diff
>>
>> Cheers,
>>
>> Antony
>
>
> It looks like a good start. I'll do some testing this morning,
>
> Two related issues we should consider fixing:
> * Forwarding the values of all select fields in the form
> * Most importantly, "More fields" should forward the currently selected
> product. See comment in (1).
>
> (1) http://markmail.org/message/5enlgw4jsdyhce6u
Re: [Apache Bloodhound] #617: Switching from QCT to full create
ticket page loses field values
Posted by Ryan Ollos <ry...@wandisco.com>.
On Sun, Dec 8, 2013 at 6:31 AM, Antony Semonella <as...@gmail.com>wrote:
> Hello all,
>
> The following patch will fix #617:
>
>
> https://issues.apache.org/bloodhound/attachment/ticket/617/preserve_qct_fields.diff
>
> Cheers,
>
> Antony
It looks like a good start. I'll do some testing this morning,
Two related issues we should consider fixing:
* Forwarding the values of all select fields in the form
* Most importantly, "More fields" should forward the currently selected
product. See comment in (1).
(1) http://markmail.org/message/5enlgw4jsdyhce6u