bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ollos <ryan.ol...@wandisco.com>
Subject Re: [Apache Bloodhound] #710: Failed to batch modify tickets to set resolution=duplicate
Date Mon, 11 Nov 2013 08:41:35 GMT
On Fri, Nov 8, 2013 at 7:17 AM, Gary Martin <gary.martin@wandisco.com>wrote:

> On 07/11/13 20:56, Olemis Lang wrote:
>
>> On Tue, Nov 5, 2013 at 2:59 AM, Ryan Ollos <ryan.ollos@wandisco.com>
>> wrote:
>>
>>  On Mon, Nov 4, 2013 at 11:57 PM, Apache Bloodhound <
>>> dev@bloodhound.apache.org> wrote:
>>>
>>>  #710: Failed to batch modify tickets to set resolution=duplicate
>>>> ---------------------------+----------------------------------
>>>>    Reporter:  olemis        |      Owner:  olemis
>>>>        Type:  defect        |     Status:  closed
>>>>    Priority:  blocker       |  Milestone:  Release 8
>>>>   Component:  multiproduct  |    Version:  0.7.0
>>>> Resolution:  fixed         |   Keywords:  ticket, batch modify
>>>> ---------------------------+----------------------------------
>>>> Changes (by rjollos):
>>>>
>>>>   * owner:   => olemis
>>>>
>>>>
>>>> --
>>>> Ticket URL: <https://issues.apache.org/bloodhound/ticket/710#comment:6>
>>>> Apache Bloodhound <https://issues.apache.org/bloodhound/>
>>>> The Apache Bloodhound issue tracker
>>>>
>>>>
>>> As to fixing the underlying problem, that the duplicate ticket relation
>>> isn't added to the `ticket_change` table, I started working on fixing
>>> that
>>> and my changes so far can be found in (1). `ITicketManipulator` isn't
>>> called on batch modification, which presents a bit of a problem since the
>>> `duplicate` attribute is added during the validation. There doesn't seem
>>> to
>>> be any way to validate batch modifications. I'm led to the conclusion
>>> that
>>> we need to either implement ITicketManipulator for batch modifications,
>>> or
>>> add a different extension point, `IBatchTicketManipulator`.
>>>
>>> (1) https://github.com/rjollos/bloodhound/compare/trunk...t710
>>>
>>
>> The resource changed interfaces discussed in t.e.o issue tracker should
>> deal with batch updates . I'm not fond of adding new interfaces to do
>> exactly the same thing others do ... though I might be missing something
>>
>>
> There is only one ticket with a mention of IResourceChanged and that is
> pretty old. Is there something else I should be looking for? If I
> understand the issue it looks like something that should be fixed fairly
> soon though it doesn't seem to be a blocker.
>
> Cheers,
>     Gary
>

The Trac ticket Olemis was referring to is #11148. I'm not sure the
ResourceChangeListener will work in this case, since we need to intercept
the event before the resource is changed.

However, I think it will be possible to fix this without needing another
hook since we already subclass BatchModifyModule in
multiproduct.ticket.batch and can do the validation directly in the request
handler.

http://trac.edgewall.org/ticket/11148

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message