bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [Apache Bloodhound] #146: Inline editing of objects
Date Wed, 28 Nov 2012 06:59:31 GMT
On 11/27/12, Gary Martin <> wrote:
> On 27/11/12 16:00, Olemis Lang wrote:
>> On 11/23/12, Gary Martin <> wrote:
>> [...]
>>> Or something like that. So, apart from a clear idea of how we clearly
>>> mark fields as edited, are there any other holes in this? It is also
>>> worth considering if this fits with the current mechanisms for guarding
>>> against conflicts dues to concurrent edits.
>> Yes. I notice a gap here (unless I'm missing something ...) , and it
>> is related to ticket workflow . Inline edits have to pass through
>> workflow . Ideally we could always force `leave` action on in place
>> edits but if Modify Ticket section won't be there then what shall we
>> do ?
> I wouldn't say that changes to the ticket details imply a change of
> ticket status within the workflow so I was hoping to leave this as a
> separate proposal.

A change of ticket status ? Well , no . You are right . That's what
built-in leave action is for . However IMO edits must always pass
through workflow . If action=leave nothing remarkable happens though .

> However, it does seem worthy of comment as there are a few
> inconsistencies.


> For example, it would be nice to be able to change the
> "assigned to" user but the ability to do that is dependent on workflow
> too. Meanwhile "reported by" could be considered an in-place edit. A
> similar thing happens with the status and ticket type fields that are
> close together. The attempts to change the workflow related items would
> probably have to either send you to the "Action" control or present you
> with the control somehow.

I'd rather prefer to see workflow actions when editing other fields as well .

OTOH , editing «owner» leads to the ambiguous situation when there are
many choices to assign a ticket to somebody (e.g. info request ,
review , assign to , test , ...) . Not to mention and custom workflow
actions / controllers and related side-effects happening at once .
This makes me wander whether it's better (correct ?) to focus on
workflow actions rather than fields when analyzing this particular
subject from a user experience perspective .

> At this point I really have to see what those with more knowledge of ui
> design will come up with though.

beyond UI , or UX ... it may also be about domain / business logic ,
and workflow semantics



Blog ES:
Blog EN:

Featured article:

View raw message