Create Ticket

Reporter:
Opened:
Type:
enhancement  
Status:
closed : fixed  
Priority:
Milestone:
Component:
Version:
 
Description

Objects such as Tickets, Milestones, Versions and Products should be editable in place, rather than via a separate 'modify' or 'change' section.

Cc:
 

Attachments

bh_theme_x_66_ticket_inplace_select.png (67.2 KB) - added by olemis 22 months ago.
Screenshot #146 : In place editable select ticket field
t146_r1386655_jeditable.diff (24.8 KB) - added by olemis 22 months ago.
Patch: BH Dashboard #146: jEditable files
t146_r1386655_jeditable_custom.diff (1.0 KB) - added by olemis 22 months ago.
Patch: BH Dashboard #146: Enhanced jEditable
t146_r1386655_jquery_iphone_checkbox.diff (20.9 KB) - added by olemis 22 months ago.
Patch: BH Dashboard #146 : Including jQuery iphone-style-checkboxes ( http://github.com/tdreyno/iphone-style-checkboxes )
bh_theme_x_70_ticket_inplace_iphone_cb.png (86.2 KB) - added by olemis 22 months ago.
Screenshot #146 : On / off state of iPhone toggle buttons (ticket view)
bh_theme_x_71_ticket_inplace_radio.png (65.8 KB) - added by olemis 22 months ago.
Screenshot #146 : Dropdown menu used in inplace editor for ticket radio field
t146_r1386655_bheditable.diff (12.4 KB) - added by olemis 22 months ago.
Patch: BH Dashboard #146 : Bloodhound in-place edit arquitecture (frontend)
t146_r1386655_bheditable_submit.diff (868 bytes) - added by olemis 22 months ago.
Patch: BH Dashboard #146 : Bloodhound in-place edit arquitecture (backend)
t146_r1386655_inplace_ticket.diff (8.8 KB) - added by olemis 22 months ago.
Patch: BH Theme #146 : Inplace editing in ticket view
t146_r1386655_inplace_ticket_backend.diff (46.5 KB) - added by olemis 22 months ago.
Patch: BH Theme #146 : Handle submit requests generated by in-place editors in ticket view
t146_r1418195_scrollspy_btn.diff (2.3 KB) - added by olemis 19 months ago.
BH Theme #146 : Transform navbar into button toolbar in ticket scroll spy
t146_r1418195_inplace_ticket_fields.diff (4.0 KB) - added by olemis 19 months ago.
Patch: BH Theme #146 : Edit ticket fields in place
bh_theme_x_86_ticket_responsive_view_state.png (50.3 KB) - added by olemis 19 months ago.
Screenshot: Enhanced ticket view (view state)
bh_theme_x_87_ticket_responsive_edit_state.png (39.4 KB) - added by olemis 19 months ago.
Screenshot #146: Enhanced ticket view (editable state)
bh_theme_x_90_ticket_responsive_edit_all.png (30.1 KB) - added by olemis 19 months ago.
Screenshot #146 : Editing all ticket fields in place
t146_r1418195_ticket_header.diff (7.7 KB) - added by olemis 19 months ago.
Patch: BH Theme #146 : Improved ticket header
t146_r1420132_inplace_ticket_fields.diff (4.3 KB) - added by olemis 19 months ago.
Patch: BH Theme #146 : Edit ticket fields in place
t146_r1420132_inplace_ticket_desc.diff (3.3 KB) - added by olemis 19 months ago.
Patch: BH Theme #146 : Edit special fields (e.g. summary, description, ...)
t146_r1420132_inplace_ticket_form.diff (16.0 KB) - added by olemis 19 months ago.
Patch: BH Theme #146 : In-place editing form
bh_theme_x_91_ticket_responsive_submit_workflow.png (133.2 KB) - added by olemis 19 months ago.
Screenshot #146 : Drop down menu for ticket workflow actions

Download all attachments as: .zip


Change History

jdreimann

  • Summary changed from In-place editing of objects to Inline editing of objects

olemis

So what shall we do about this ticket ?
Is it ok to use jEditable for this ?
If the decision is to move forward with another library then which one ?

jdreimann

Am I right in thinking that the licensing question regarding jEditable raised by Gary previously hasn't been resolved yet?

olemis

The way I see it we have three options :

  1. Use jEditable except auto-grow plugin.
    • We'd have to decide whether this is a crucial feature
  2. Use jEditable and implement a replacement for auto-grow functionality
    • We'd have to assess whether this is a feasible task
  3. Do not use jEditable at all, and choose a similar library
    • So far I have not found something as complete as jEditable , especially supporting integrate of the editor with server-side WikiFormatting renderer .
    • I'm not an expert and I have not exhausted all the possibilities

Beyond that , there is something else we need to discuss . If Modify / Change will disappear then what is supposed to happen when Javascript is disabled ?

23 months ago

comment:5  

In reply to: ↑ 4

Follow-up:

jdreimann

Replying to olemis:

[...] If Modify / Change will disappear then what is supposed to happen when Javascript is disabled ?

How about they stay until Javascript removes them? Or what would you suggest?

23 months ago

comment:6  

In reply to: ↑ 5

olemis

Replying to jdreimann:

Replying to olemis:

[...] If Modify / Change will disappear then what is supposed to happen when Javascript is disabled ?

How about they stay until Javascript removes them?

That's ok afaics.

jdreimann

  • Priority changed from major to critical
23 months ago

comment:8  

In reply to: ↑ 4

gjm

Replying to olemis:

The way I see it we have three options :

  1. Use jEditable except auto-grow plugin.
    • We'd have to decide whether this is a crucial feature

OK, go with option 1. We can at least see if the autogrow functionality is missed

olemis

  • Owner changed from nobody to olemis
  • Status changed from new to accepted

olemis

Screenshot #146 : In place editable select ticket field

olemis

I have attached two patches . The former incorporates jeditable files into dashboard plugin . I have detected that the library uses built-in eval() function to parse JSON strings rather than safe functions e.g. $.parseJSON() . That's a potential security hole afaics . What shall we do about that ?

The later patch implements Bloodhound editable architecture , data API , adds default settings to insert submit button plus a new editable type named bhselect supporting option groups . It is still work in progress (so it will be changed in the near future) . However it is offered for the moment as a preview of what's been done in this direction .

Both patches have been used to build preliminary incomplete implementation in ticket view . The following screenshot illustrates what it looks like . Feedback is welcome .

Screenshot #146 : In place editable select ticket field

Disclaimer Please do not commit any of these yet , just have fun for the moment .

Last edited 22 months ago by olemis (previous) (diff)
22 months ago

comment:11  

In reply to: ↑ 10

Follow-up:

jdreimann

Replying to olemis:

The following screenshot illustrates what it looks like . Feedback is welcome .

I assume the button with the check mark is to confirm the selection and 'commit' it? This should not be required. Part of the case for inline editing is that confirmation is only required when

  1. It's difficult (time, effort) or impossible to revert fully.
  2. Automatically saved information would be incomplete.

An example for 1. is when a ticket is when stuff gets deleted. An example for 2. is changing a ticket description, which you probably wouldn't want to change for everyone before you're done typing.

I think we'll get closer to a proper definition by trial and error, but I think our default approach should be to not ask for confirmation unless in cases of grave danger.

22 months ago

comment:12  

In reply to: ↑ 11

Follow-up:

olemis

Replying to jdreimann:

Replying to olemis:

The following screenshot illustrates what it looks like . Feedback is welcome .

I assume the button with the check mark is to confirm the selection and 'commit' it?

yes

This should not be required.

ok. I'll remove that for select fields .

Part of the case for inline editing is that confirmation is only required when

  1. It's difficult (time, effort) or impossible to revert fully.
  2. Automatically saved information would be incomplete.

An example for 1. is when a ticket is when stuff gets deleted. An example for 2. is changing a ticket description, which you probably wouldn't want to change for everyone before you're done typing.

IMO submit button does need to be required for all kinds of text fields (i.e. raw &wiki textarea, raw and wiki text field ) . Consider the case when user starts typing but suddenly decides it's all wrong . Hence there should be a way to revert in place edits (e.g. Submit + Cancel button ?)

I think we'll get closer to a proper definition by trial and error, but I think our default approach should be to not ask for confirmation unless in cases of grave danger.

... and when there's a need to cancel / undo in place modifications , like is the case for text fields .

22 months ago

comment:13  

In reply to: ↑ 12

jdreimann

Replying to olemis:

IMO submit button does need to be required for all kinds of text fields

and

.. there's a need to cancel / undo in place modifications , like is the case for text fields .

Yep, that's what I was trying to say :)
+1

olemis

I have refreshed one of the patches submitted before for dashboard plugin. Changes are :

  • Inplace editor for wiki textarea (bhwiki)

However it's not finished yet , because wiki toolbar is not usable due to the fact that editor disappears on clicking the toolbar itself . I guess this happens because its outside expected editor area ... but not sure yet of how to fix it .

In my local patch queue repository they have been tested against dashboard plugin @ r1386655 after applying them in the following order

$ hg qapplied
t146/t146_r1386655_jeditable.diff
t146/t146_r1386655_bheditable.diff
t146/t146_r1386655_bheditable_submit.diff

Besides I added a new one for theme plugin mainly modifying ticket view to incorporate in-place editors. I tested by applying it on top of patches submitted to #203 , #206 , #208 and #211 against theme plugin @ r1386655 using my local patch queue repository .

$ hg qapplied
t203/t203_r1386655_wiki_toolbar.diff
t211/t211_r1386655_texarea_resizer.diff
t208/t208_r1386655_inline_ticket_radio.diff
t206/t206_r1386655_ticket_textarea_fields.diff
t206/t206_r1386655_ticket_desc_top.diff
t146/t146_r1386655_inplace_ticket.diff
t146/t146_r1386655_inplace_ticket_backend.diff

Disclaimer Like I said before , this is still work in progress .

Last edited 22 months ago by olemis (previous) (diff)

olemis

Patch order updated after splitting original patch for #203

olemis

Patch: BH Dashboard #146: jEditable files

olemis

Patch: BH Dashboard #146: Enhanced jEditable

olemis

Patch: BH Dashboard #146 : Including jQuery iphone-style-checkboxes ( http://github.com/tdreyno/iphone-style-checkboxes )

olemis

Screenshot #146 : On / off state of iPhone toggle buttons (ticket view)

olemis

After a lot of fighting against external js libs , I think I won the first battle and managed to implement in place editor for ticket checkbox fields . I have refreshed patches accordingly and updated application order mentioned before in comment:14 . Only frontend has been improved so it's still work in progress at the moment , as the backend still needs to be developed .

New features described below .

Dashboard plugin

  • iPhone style checkboxes js library added . MIT license
  • Modifications for jEditable .
  • Architecture of Bloodhound editable data API modified to support references to functions in data-edit* attributes (by using javascript: prefix) .
  • iPhone checkbox jEditable type ... some minor enhancements still needed .

Theme plugin

  • Enhanced code to load values for select and checkbox fields
  • Changes for iPhone checkbox editable type propagated to render these controls in ticket view .

This is closer to completion now ... at least the frontend is almost ready . This is what iPhone checkboxes look like . Feedback is welcome .

Screenshot #146 : On / off state of iPhone toggle buttons (ticket view)

Only editors for radio ticket type are missing ... coming soon .

22 months ago

comment:17  

In reply to: ↑ 16

Follow-up:

jdreimann

Replying to olemis:

This is closer to completion now ... at least the frontend is almost ready . This is what iPhone checkboxes look like . Feedback is welcome .

Where does the requirement for iPhone checkboxes come from? I don't remember this being discussed anywhere. If you want to implement them, please propose that in a separate ticket. In this ticket, please focus on enabling inline edits.

For now I'd appreciate if you would remove them from proposed patches because they are inconsistent with the current design and were never designed for mouse-operation. Not even Apple uses them in their desktop software, apart from a handful exceptions.

22 months ago

comment:18  

In reply to: ↑ 17

olemis

Replying to jdreimann:

Replying to olemis:

This is closer to completion now ... at least the frontend is almost ready . This is what iPhone checkboxes look like . Feedback is welcome .

Where does the requirement for iPhone checkboxes come from? I don't remember this being discussed anywhere.

just a suggestion ...

If you want to implement them, please propose that in a separate ticket. In this ticket, please focus on enabling inline edits.

... so if this is not correct I revert those changes and use plain-old checkboxes . No big deal .

Now I ask , what inplace radio ticket fields editor will look like ?

For now I'd appreciate if you would remove them from proposed patches because they are inconsistent with the current design and were never designed for mouse-operation.

ok

olemis

I have refreshed and uploaded two patches . I've also erased patches introducing iPhone style checkboxes from my local patch queue . Hence I've also updated patch order . Main changes are :

  • Use plain old checkboxes
  • Inplace editor for ticket radio fields . Please take a look at image below . Feedback is welcome

Screenshot #146 : Dropdown menu used in inplace editor for ticket radio field

olemis

Screenshot #146 : Dropdown menu used in inplace editor for ticket radio field

olemis

Patch: BH Dashboard #146 : Bloodhound in-place edit arquitecture (frontend)

olemis

Patch: BH Dashboard #146 : Bloodhound in-place edit arquitecture (backend)

olemis

Patch: BH Theme #146 : Inplace editing in ticket view

olemis

Patch: BH Theme #146 : Handle submit requests generated by in-place editors in ticket view

olemis

I've added one or two more patches and refreshed all others . New features are :

  1. Wiki toolbar buttons are usable now
  2. By default in-place submit requests are sent to current URL with inplace = submit and form token set .
  3. Hence requests handled by ticket module are intercepted to handle in-place submit requests .
  4. However , some refactorings are needed mainly because the former characteristics imply that in-place edits must be powered by a single component (instead of two like it happens now).
  5. I've moved helper functions related to tickets (i.e. create function borrowed from TracHacks:XmlRpcPlugin @ r12099 ) onto a separate module . I've also incorporated TicketRPC's update and get methods .
  6. The version of update method incorporated has been slightly modified considering this comment
  7. All rpc methods have been slightly modified to use them as standalone functions .
  8. In place components in new module so as to enable / disable at once .
  9. In place edits take place and are reflected correctly in the UI .
  10. Minor changes to ticket templates .

PS: I've update patch order too.

Last edited 22 months ago by olemis (previous) (diff)
22 months ago

comment:21  

In reply to: ↑ 19

jdreimann

Replying to olemis:

Inplace editor for ticket radio fields . Please take a look at image below .
Feedback is welcome

Looks good to me.

olemis

  • Keywords inplace bheditable added

olemis

Attached patches have to be refreshed after #217 , #223 and especially considering enhancements in ticket fields UI .

olemis

  • Owner olemis deleted
  • Status changed from accepted to needinfo

Work on this ticket is suspended until we figure out how in-place editing should work . Open discussion's been held in bloodhound-dev@…

olemis

  • Status changed from needinfo to assigned

Instructions confirmed in a message sent to bloodhound-dev ML .

I'll start working on this following suggestions provided by gjm and jdreimann .

olemis

  • Owner set to olemis
  • Status changed from assigned to accepted

olemis

BH Theme #146 : Transform navbar into button toolbar in ticket scroll spy

olemis

Patch: BH Theme #146 : Edit ticket fields in place

olemis

Screenshot: Enhanced ticket view (view state)

olemis

Screenshot #146: Enhanced ticket view (editable state)

olemis

The new approach to in-place editing in ticket view is not compatible with jEditable afaics . Hence I've built everything from scratch . Attached patches against theme plugin add the following features :

  1. Enhanced ticket fields list updated according to responsive mockups
  2. Enhanced scroll spy nav bar implemented with Bootstrap button groups like sketched in responsive mockups
  3. Modify ticket section is gone
  4. On clicking Modify Ticket button in scroll spy nav bar , ticket view enters editable state (suggested by jure)

Patches should be applied against bloodhound_theme @ r1418195 r1420132 1421336 in the following order :

$ hg qapplied
t146/t146_r1418195_ticket_header.diff
t146/t146_r1420132_inplace_ticket_fields.diff
t146/t146_r1420132_inplace_ticket_desc.diff
t146/t146_r1420132_inplace_ticket_form.diff

Issues found so far :

  1. In editable state scroll spy does not activate nav item accurately. This happens because heights are different (e.g. wiki toolbar added on top of some textarea elements , etc ...) to the values when scroll spy was installed.

... /me figuring out how to fix ( let's improve this on a separate ticket ) .

After all this ticket view will look like shown below in view mode ...

Screenshot: Enhanced ticket view (view state)

... and in editable mode ...

Screenshot #146: Enhanced ticket view (editable state)

Still there are many open questions :

  1. What happens after ticket enters editable state ? ( see comment:36 )
  2. What about workflow actions now that Modify Ticket section is gone? ( see comment:36 )
  3. Should description, keywords and summary be put into editable as well (... IMO they should , I'm just looking for confirmation ...) ? ( see comment:32 )

Feedback is welcome .

Last edited 19 months ago by olemis (previous) (diff)
19 months ago

comment:28  

In reply to: ↑ 27

Follow-up:

gjm

Replying to olemis:

  1. What happens after ticket enters editable state ?

after edits we clearly need a Submit Changes button and a cancel button. Submission and cancelling probably imply a change back to the non-editable state so perhaps we need a revert button that only resets the fields as well?

  1. What about workflow actions now that Modify Ticket section is gone?

We still need the modify ticket area for that until there is an alternative solution for workflow.

  1. Should description, keywords and summary be put into editable as well (... IMO they should , I'm just looking for confirmation ...) ?

Yes.. until otherwise noted, we will require that.

19 months ago

comment:29  

In reply to: ↑ 28

Follow-up:

jdreimann

Replying to gjm:

Replying to olemis:

  1. What happens after ticket enters editable state ?

after edits we clearly need a Submit Changes button and a cancel button. Submission and cancelling probably imply a change back to the non-editable state so perhaps we need a revert button that only resets the fields as well?

I think Submit button and a Cancel button (with btn-link class to show it's a secondary action) will be enough.

  1. What about workflow actions now that Modify Ticket section is gone?

We still need the modify ticket area for that until there is an alternative solution for workflow.

What stops us from workflow simply being a dropdown of options? review, resolve, info request etc.

  1. Should description, keywords and summary be put into editable as well (... IMO they should , I'm just looking for confirmation ...) ?

Yes.. until otherwise noted, we will require that.

+1

19 months ago

comment:30  

In reply to: ↑ 29

gjm

Replying to jdreimann:

Replying to gjm:

Replying to olemis:

  1. What happens after ticket enters editable state ?

after edits we clearly need a Submit Changes button and a cancel button. Submission and cancelling probably imply a change back to the non-editable state so perhaps we need a revert button that only resets the fields as well?

I think Submit button and a Cancel button (with btn-link class to show it's a secondary action) will be enough.

Fair enough.. certainly good enough for now

  1. What about workflow actions now that Modify Ticket section is gone?

We still need the modify ticket area for that until there is an alternative solution for workflow.

What stops us from workflow simply being a dropdown of options? review, resolve, info request etc.

I was thinking a similar way but the control is a little more complicated in needing a second input to change assignment for some actions. I don't know if there would be more cases to take into account with plugins that extend the functionality of course.

  1. Should description, keywords and summary be put into editable as well (... IMO they should , I'm just looking for confirmation ...) ?

Yes.. until otherwise noted, we will require that.

+1

gjm

Note: t146/t146_r1418195_scrollspy_btn.diff committed as part of #295

olemis

Screenshot #146 : Editing all ticket fields in place

olemis

Patch: BH Theme #146 : Improved ticket header

olemis

I have submitted new files to rebase patches against r1420132 . Patch order in comment:27 updated accordingly . I have also added a new patch to edit special ticket fields , namely description, keywords, summary and reporter . At present they will remain in view state if permissions are not sufficient . Other minor enhancements have been added like tagging editable fields with data-edit="inplace" , custom textarea size , etc ...

Anyway , after all this editable state will look like shown below :

Screenshot #146 : Editing all ticket fields in place

19 months ago

comment:33  

In reply to: ↑ 32

Follow-up:

jdreimann

Replying to olemis:

[...] Anyway , after all this editable state will look like shown below :

[img]

I assume the look of the drop down button and the red background for selected radio button/checkbox are browser dependent? Just checking to make sure it isn't styled that way.

Last edited 19 months ago by jdreimann (previous) (diff)
19 months ago

comment:34  

In reply to: ↑ 33

olemis

Replying to jdreimann:

Replying to olemis:

[...] Anyway , after all this editable state will look like shown below :

[img]

I assume the look of the drop down button and the red background for selected radio button/checkbox are browser dependent?

Browser dependent. Would be nice to have consistent look and feel across different platforms .

Just checking to make sure it isn't styled that way.

;)

olemis

btw ... /me finishing . Will let you know soon . Later today .

olemis

Patch: BH Theme #146 : Edit ticket fields in place

olemis

Patch: BH Theme #146 : Edit special fields (e.g. summary, description, ...)

olemis

Patch: BH Theme #146 : In-place editing form

olemis

Screenshot #146 : Drop down menu for ticket workflow actions

olemis

  • Owner changed from olemis to jdreimann
  • Status changed from accepted to review

After comment:32 I have refreshed previous patches and attached new patch implementing ticket submission . Patch order in comment:27 updated accordingly . Other minor enhancements have been added consisting of :

summary: BH Theme #146 : In-place submit form . Sticky panel relocated and other minor changes
summary: BH Theme #146 : Discard inline modifications
summary: BH Theme #146 : Tooltips for workflow actions
summary: BH Theme #146 : Edit mode not reentrant plus .editing => .edit-active
summary: BH Theme #146 : Workflow drop down visible on affix
summary: BH Theme #146 : Use JS templates to render in-place submit controls
summary: BH Theme #146 : Ticket in-plece submit controls

Anyway , after all this editable state will look like shown below :

Screenshot #146 : Drop down menu for ticket workflow actions

I'm forwarding ticket for further review of workflow drop down menu from a UI/UX perspective .

A few comments on that subject .

  1. Update / cancel buttons placed in sticky panel so that they'll always be handy in edit mode
  2. Update button highlighted (btn-primary) because it has to be that relevant on edit mode . Otherwise it's hard to notice since it shows up out of nowhere .
  3. Reduced space => reduced visibility of action hints (i.e. tooltips)
  4. Selected workflow action appended to Update label to allow one click edits . Otherwise it is obscured the intentions and difficult to figure out what's gonna happen with ticket in the end .

Beyond this , there should be some room for enhancements . That's sure . I suggest to tackle improvements on separate tickets .

jdreimann

  • Owner changed from jdreimann to gjm

I assume the textfield next to the Update button is the ticket summary?
I would change the button style from btn-primary to btn-warning or btn-danger for higher contrast, but other than that I'd say +1 to commit this so we can actually run it locally and improve on what's built already. This ticket has been going on for too long and unwieldy.

19 months ago

comment:38  

In reply to: ↑ 37

olemis

Replying to jdreimann:

I assume the textfield next to the Update button is the ticket summary?

yes , placeholder = Ticket summary

I would change the button style from btn-primary to btn-warning or btn-danger for higher contrast,

fwiw +1 for btn-warning

gjm

This looks pretty good for committing. There are a few issues left but I think it is probably better to commit this work and raise new tickets for any required tweaks.

19 months ago

comment:40  

In reply to: ↑ 39

olemis

Replying to gjm:
[...]

There are a few issues left

I've detected some potential issues too ... low priority afaics .

but I think it is probably better to commit this work and raise new tickets for any required tweaks.

I'm ok with that approach .

gjm

r1427698 applies t146_r1418195_ticket_header.diff

r1427699 applies t146_r1420132_inplace_ticket_fields.diff

r1427702 applies t146_r1420132_inplace_ticket_desc.diff

r1427717 applies t146_r1420132_inplace_ticket_form.diff

thanks olemis.

gjm

  • Resolution set to fixed
  • Status changed from review to closed

Calling this complete - further enhancements in new tickets.

Note: See TracTickets for help on using tickets.

Activity

  

Warning   No events reported for enhancement: Inline editing of objects (closed: fixed) in the last 30 days since Jul 13, 2014. This may happen if system is not configured correctly. Please contact your administrator if you think this is the case.