Bug 11360 - Disable barcode field and submit button when a hold is found
Summary: Disable barcode field and submit button when a hold is found
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Nick Clemens
QA Contact: Jonathan Druart
URL:
Keywords:
: 6392 11899 (view as bug list)
Depends on: 16942
Blocks: 18438
  Show dependency treegraph
 
Reported: 2013-12-09 20:04 UTC by Kyle M Hall
Modified: 2018-12-05 15:17 UTC (History)
15 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 11360 - Disable barcode field and submit button when a hold is found (3.70 KB, patch)
2013-12-09 20:30 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 11360 - Disable barcode field and submit button when a hold is found (3.76 KB, patch)
2013-12-10 01:05 UTC, Biblibre Sandboxes
Details | Diff | Splinter Review
Bug 11360 - Disable barcode field and submit button when a hold is found (3.82 KB, patch)
2013-12-13 12:00 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 11360 - Disable barcode field and submit button when a hold is found (17.64 KB, patch)
2015-11-18 18:54 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 11360 - Disable barcode field and submit button when a hold is found (17.83 KB, patch)
2015-11-20 12:22 UTC, Kyle M Hall
Details | Diff | Splinter Review
Screenshot of layout issues (24.94 KB, image/png)
2015-11-24 15:57 UTC, Owen Leonard
Details
Bug 11360 - Disable barcode field and submit button when a hold is found (17.91 KB, patch)
2016-02-03 14:47 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 11360 - Disable barcode field and submit button when a hold is found (18.55 KB, patch)
2016-03-07 14:33 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 11360 - Disable barcode field and submit button when a hold is found (18.53 KB, patch)
2016-03-08 15:43 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 11360 - Disable barcode field and submit button when a hold is found (18.55 KB, patch)
2016-04-18 15:21 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 11360 - Disable barcode field and submit button when a hold is found (18.62 KB, patch)
2016-06-02 16:19 UTC, Biblibre Sandboxes
Details | Diff | Splinter Review
Bug 11360 - Disable barcode field and submit button when a hold is found (18.64 KB, patch)
2016-07-07 20:17 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 11360 [QA Followup] - Fix styles and button order (3.95 KB, patch)
2016-07-20 15:59 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 11360 - Disable barcode field and submit button when a hold is found (18.71 KB, patch)
2016-07-25 13:47 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 11360 [QA Followup] - Fix styles and button order (4.02 KB, patch)
2016-07-25 13:47 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2013-12-09 20:04:26 UTC
At the moment when scanning in returns, it can be easy to miss a hold trap due to the fact that the barcode and submit are still active and the barcode field is focused on. A librarian who is focused on scanning can easily scan another item and pass over the form, which is equivalent to clicking the "ignore" button.
Comment 1 Kyle M Hall 2013-12-09 20:30:47 UTC Comment hidden (obsolete)
Comment 2 Biblibre Sandboxes 2013-12-10 01:05:13 UTC
Patch tested with a sandbox, by Christopher Brannon <cbrannon@cdalibrary.org>
Comment 3 Biblibre Sandboxes 2013-12-10 01:05:35 UTC Comment hidden (obsolete)
Comment 4 Christopher Brannon 2013-12-10 01:10:07 UTC
Looks good.  I tested in a sandbox and it did what was expected.  Hold trap failed before the patch applied, and then the hold trap worked after.  I like that the barcode field is completely deactivated, rather than the hold trap just taking the focus off.  This forces you to push a button.

Our current jquery that addresses this just takes the focus off.  We tossed around the idea of deactivating the barcode field altogether, but didn't have the nerve to do that much.  I think the behavior is acceptable and expected.

Christopher
Comment 5 Owen Leonard 2013-12-10 16:03:26 UTC
Sorry to come late to this patch, but I want to jump in:

Is there any reason to show the input field at all if it's disabled? We are inconsistent on the checkout page. Sometimes the input is displayed as disabled, sometimes it is hidden. I think we should stick with hiding the input (and the "options" checkboxes too in this case) if the user cannot interact with them.
Comment 6 Christopher Brannon 2013-12-10 21:54:51 UTC
Owen,
Can you provide any examples of when the field is hidden?  I was unaware it did this.  Maybe I have not been in a circumstance that it has.

Christopher
Comment 7 Liz Rea 2013-12-13 01:57:17 UTC
putting the hold notification in a modal window might be nice here as well - something that greys the screen and puts the hold notice on top (with a non-js fallback, of course)
Comment 8 Jonathan Druart 2013-12-13 12:00:25 UTC
(In reply to Owen Leonard from comment #5)
> Is there any reason to show the input field at all if it's disabled? We are
> inconsistent on the checkout page. Sometimes the input is displayed as
> disabled, sometimes it is hidden. I think we should stick with hiding the
> input (and the "options" checkboxes too in this case) if the user cannot
> interact with them.

Owen, could you explain this point please?
This patch impacts the check-in page and I don't know where there is hidden fields.
To me it is consistent to disable the input and the submit button here.

(In reply to Liz Rea from comment #7)
> putting the hold notification in a modal window might be nice here as well -
> something that greys the screen and puts the hold notice on top (with a
> non-js fallback, of course)

It is out-of-the-scope of this bug. Maybe could you open a new report for that?

Marked as Passed QA.
Comment 9 Jonathan Druart 2013-12-13 12:00:47 UTC Comment hidden (obsolete)
Comment 10 Galen Charlton 2013-12-13 18:06:13 UTC
This patch can lead to a situation where the barcode form and button is disabled without providing the staff member any way of enabling it (short of use the back button or the like).  Specifically, this occurs if an item that does /not/ fill a hold and which does not already have an active branchtransfer record is checked in a library other than its home.  The staff member can print a transfer slip, but doing so does not enable the barcode input form.

Marking as failed QA.
Comment 11 Galen Charlton 2013-12-13 18:19:09 UTC
By the way, my gut feeling is that taking up Liz's suggestion using modal dialog windows for checkin conditions that require staff acknowledgement would help avoid the sort of regression I found.
Comment 12 Christopher Brannon 2013-12-16 16:36:38 UTC
There are a couple approaches you could go from here.

Currently we have a jquery setup that simply takes the focus off the input box.  It doesn't disable anything.  This has been a successful adjustment for us.  You might think that this is a loose fix, as you can click on the text box and continue on, but it is really no different than clicking the ignore button.

The other approach is to fix the patch to re-enable the input box and button for transfers.

I don't know if it is worth going to a modal dialog window in this one function.  It isn't a consistent workflow throughout Koha.  When you start to do things differently in different parts of the software, it really breaks down workflow.  I think modal dialog windows would be great for many alert messages throughout Koha, but it needs to be consistent throughout, otherwise workflow is disrupted, and you might look for these alerts one way and not the other.

Christopher
Comment 13 Galen Charlton 2013-12-16 18:26:22 UTC
(In reply to Christopher Brannon from comment #12)
> I don't know if it is worth going to a modal dialog window in this one
> function.  It isn't a consistent workflow throughout Koha.  When you start
> to do things differently in different parts of the software, it really
> breaks down workflow.  I think modal dialog windows would be great for many
> alert messages throughout Koha, but it needs to be consistent throughout,
> otherwise workflow is disrupted, and you might look for these alerts one way
> and not the other.

I agree about consistency, but from the other direction: namely, Bootstrap modals are only used in a couple places currently, but if folks generally think that they're a good direction to go in, then circulation is a good place to get started with adding more use of them: it's faster for a circ operator to dismiss a modal than to wait for a round-trip to the server with the current approach for dealing with blocking alerts during circ operations.
Comment 14 Kyle M Hall 2015-11-18 18:52:54 UTC
> I agree about consistency, but from the other direction: namely, Bootstrap
> modals are only used in a couple places currently, but if folks generally
> think that they're a good direction to go in, then circulation is a good
> place to get started with adding more use of them: it's faster for a circ
> operator to dismiss a modal than to wait for a round-trip to the server with
> the current approach for dealing with blocking alerts during circ operations.

I concur!
Comment 15 Kyle M Hall 2015-11-18 18:54:29 UTC Comment hidden (obsolete)
Comment 16 Nick Clemens 2015-11-18 23:11:23 UTC
So, I don't have a barcode scanner at my desk, but if I simulate just typing in a barcode and pressing enter while the modal is up I can still just check in the next item
Comment 17 Nick Clemens 2015-11-19 15:20:40 UTC
To be more clear:

Failing QA because the input box is still selected and active while the modal is up.

Typing a barcode and pressing enter (i.e. scanning the next book) will check in the next item without taking any action on the hold which is the same behavior as before patch.

The modal does look very nice though and buttons seem to work as expected
Comment 18 Kyle M Hall 2015-11-20 12:22:22 UTC Comment hidden (obsolete)
Comment 19 Kyle M Hall 2015-11-20 12:23:04 UTC
(In reply to Nick Clemens from comment #17)
> To be more clear:
> 
> Failing QA because the input box is still selected and active while the
> modal is up.
> 
> Typing a barcode and pressing enter (i.e. scanning the next book) will check
> in the next item without taking any action on the hold which is the same
> behavior as before patch.
> 
> The modal does look very nice though and buttons seem to work as expected

Good catch! This new version should take care of that issue!
Comment 20 Owen Leonard 2015-11-24 15:45:07 UTC
If a checkin triggers the modal, any messages or alerts which were also triggered by the checkin will be hidden by the modal and will disappear after clearing the modal. For instance: A warning that the item was not checked out, or a checkin message which has been configured for that particular item type.

If libraries are concerned about seeing the "not checked out" message this is problematic since Bug 14821 now blocks those transactions from appearing in the table of scanned items.

And while I don't personally know what the checkin message option is used for, I don't think it's acceptable that it disappears.

Perhaps those messages should not be cleared when the modal is dismissed?
Comment 21 Owen Leonard 2015-11-24 15:57:57 UTC
Created attachment 45122 [details]
Screenshot of layout issues

This screenshot highlights a few markup/layout issues:

- The list which displays the patron information is missing the enclosing <ul></ul>
- The list shouldn't be centered. There is CSS at line 1225 of staff-global.css which aligns lists which are displayed in a message div. It should be expanded to include '.modal-body ul'
- The layout of the buttons doesn't work, but I'm not sure what to do about that.
Comment 22 Kyle M Hall 2015-11-25 15:46:25 UTC
(In reply to Owen Leonard from comment #21)
> Created attachment 45122 [details]
> Screenshot of layout issues
> 
> This screenshot highlights a few markup/layout issues:
> 
> - The list which displays the patron information is missing the enclosing
> <ul></ul>
> - The list shouldn't be centered. There is CSS at line 1225 of
> staff-global.css which aligns lists which are displayed in a message div. It
> should be expanded to include '.modal-body ul'

I removed the ul tags to make it readable. The ul styling was 'odd'. Would you be able to style the data? My css-fu isn't all that great ; )

> - The layout of the buttons doesn't work, but I'm not sure what to do about
> that.

That's really odd, because they look great on my system! Are you using any styling beyond stock Koha on your test system?
Comment 23 Owen Leonard 2016-02-01 14:08:13 UTC
Kyle I would like to look at this again. Can you please rebase?
Comment 24 Kyle M Hall 2016-02-03 14:47:58 UTC Comment hidden (obsolete)
Comment 25 Marc Véron 2016-02-22 10:17:01 UTC
Sorry, there is a merge conflict in returns.tt
Comment 26 Kyle M Hall 2016-03-07 14:33:06 UTC Comment hidden (obsolete)
Comment 27 Owen Leonard 2016-03-07 16:01:05 UTC
(In reply to Owen Leonard from comment #20)

> If a checkin triggers the modal, any messages or alerts which were also
> triggered by the checkin will be hidden by the modal and will disappear
> after clearing the modal. For instance: A warning that the item was not
> checked out, or a checkin message which has been configured for that
> particular item type.

This is still the case, and I still think it's a problem. The modal hides any other messages on the page and the messages are gone when you dismiss the modal.

Regression: This undoes Bug 15670.
Comment 28 Owen Leonard 2016-03-07 16:10:04 UTC
I personally find the default Bootstrap colored button styles to be garish and I don't think we should use them. I prefer a standard button with color added to the icons.

This is another case where we need to get some consensus before introducing a wholly new style to the interface.
Comment 29 Christopher Brannon 2016-03-07 17:50:12 UTC
(In reply to Owen Leonard from comment #28)
> I personally find the default Bootstrap colored button styles to be garish
> and I don't think we should use them. I prefer a standard button with color
> added to the icons.
> 
> This is another case where we need to get some consensus before introducing
> a wholly new style to the interface.

Our library actually uses jquery to color some buttons to make them stand out.  Frankly, I think the buttons all blend together, and I don't think colored icons wouldn't stand out enough.  I think on the staff side, if garish improves workflow and reduces errors, then bring on the garish.

Christopher
Comment 30 Kyle M Hall 2016-03-07 18:18:54 UTC
(In reply to Owen Leonard from comment #27)
> (In reply to Owen Leonard from comment #20)
> 
> > If a checkin triggers the modal, any messages or alerts which were also
> > triggered by the checkin will be hidden by the modal and will disappear
> > after clearing the modal. For instance: A warning that the item was not
> > checked out, or a checkin message which has been configured for that
> > particular item type.
> 
> This is still the case, and I still think it's a problem. The modal hides
> any other messages on the page and the messages are gone when you dismiss
> the modal.
> 

Any suggestions for how to resolve this issue?
Comment 31 Kyle M Hall 2016-03-07 18:20:21 UTC
(In reply to Christopher Brannon from comment #29)
> (In reply to Owen Leonard from comment #28)
> > I personally find the default Bootstrap colored button styles to be garish
> > and I don't think we should use them. I prefer a standard button with color
> > added to the icons.
> > 
> > This is another case where we need to get some consensus before introducing
> > a wholly new style to the interface.
> 
> Our library actually uses jquery to color some buttons to make them stand
> out.  Frankly, I think the buttons all blend together, and I don't think
> colored icons wouldn't stand out enough.  I think on the staff side, if
> garish improves workflow and reduces errors, then bring on the garish.
> 
> Christopher

I think a good compromise is to use the bootstrap buttons with the standard gray color. Garishness can easily be added via css/jQuery ; )
Comment 32 Owen Leonard 2016-03-07 18:36:16 UTC
I think it's best not to introduce new global style changes in patches which have a non-global scope. Changing the buttons just in this interface would make it break with the design of all similar interfaces.

That's not to say that we should continue to update the way Koha looks. I just think we need to do it in a more deliberate way. If folks want to develop a new standard for how we style buttons, make that proposal as a separate bug, a post to koha-devel, a wiki page, etc. Post screenshots and say, "Let's start doing things this way!" and propose a plan for updating the interface across the board.
Comment 33 Katrin Fischer 2016-03-07 18:39:00 UTC
Consistency++

That said, we can still try to make it really easy to change things using ids and classes, so that libraries can make things stand out if they choose to :)
Comment 34 Owen Leonard 2016-03-07 18:51:42 UTC
Lest all this talk of style suggest otherwise, it was the issues in comment #27 that prompted me to mark this as Failed QA.
Comment 35 Christopher Brannon 2016-03-07 18:52:47 UTC
(In reply to Kyle M Hall from comment #31)
> (In reply to Christopher Brannon from comment #29)
> > (In reply to Owen Leonard from comment #28)
> > > I personally find the default Bootstrap colored button styles to be garish
> > > and I don't think we should use them. I prefer a standard button with color
> > > added to the icons.
> > > 
> > > This is another case where we need to get some consensus before introducing
> > > a wholly new style to the interface.
> > 
> > Our library actually uses jquery to color some buttons to make them stand
> > out.  Frankly, I think the buttons all blend together, and I don't think
> > colored icons wouldn't stand out enough.  I think on the staff side, if
> > garish improves workflow and reduces errors, then bring on the garish.
> > 
> > Christopher
> 
> I think a good compromise is to use the bootstrap buttons with the standard
> gray color. Garishness can easily be added via css/jQuery ; )

As long as the buttons have distinctive IDs.  :)
Comment 36 Kyle M Hall 2016-03-07 19:05:13 UTC
(In reply to Owen Leonard from comment #34)
> Lest all this talk of style suggest otherwise, it was the issues in comment
> #27 that prompted me to mark this as Failed QA.

Which part of comment 27?
Comment 37 Owen Leonard 2016-03-07 19:11:48 UTC
(In reply to Kyle M Hall from comment #36)
> Which part of comment 27?

The whole thing!

1. The dialog obscures any other messages which might be displayed during checkin, then hides those messages when the dialog is dismissed.

2. The patch reverts the changes made by Bug 15670.
Comment 38 Kyle M Hall 2016-03-08 12:56:28 UTC
(In reply to Owen Leonard from comment #37)
> (In reply to Kyle M Hall from comment #36)
> > Which part of comment 27?
> 
> The whole thing!
> 
> 1. The dialog obscures any other messages which might be displayed during
> checkin, then hides those messages when the dialog is dismissed.
> 
> 2. The patch reverts the changes made by Bug 15670.

Let's focus on point 1 for now. What would you suggest as a fix for that?
Comment 39 Owen Leonard 2016-03-08 13:11:37 UTC
Unless there is a good case for hiding all messages, why not simply leave them there?
Comment 40 Kyle M Hall 2016-03-08 15:43:20 UTC Comment hidden (obsolete)
Comment 41 Kyle M Hall 2016-03-08 15:44:00 UTC
This latest patch should fix both of your issues Owen!
Comment 42 Jonathan Druart 2016-04-18 14:47:29 UTC
(In reply to Kyle M Hall from comment #41)
> This latest patch should fix both of your issues Owen!

Does it mean it's ready to be tested?
Comment 43 Kyle M Hall 2016-04-18 15:21:38 UTC Comment hidden (obsolete)
Comment 44 Kyle M Hall 2016-04-18 15:24:34 UTC
(In reply to Jonathan Druart from comment #42)
> (In reply to Kyle M Hall from comment #41)
> > This latest patch should fix both of your issues Owen!
> 
> Does it mean it's ready to be tested?

I do believe so!
Comment 45 Owen Leonard 2016-04-19 15:17:55 UTC
This looks good, and the test plan checks out. I do see some other instances of a <div class="dialog message"> left in the template which seem to be related to holds.

Shouldn't these cases be covered too?
Comment 46 Kyle M Hall 2016-04-19 16:17:48 UTC
(In reply to Owen Leonard from comment #45)
> This looks good, and the test plan checks out. I do see some other instances
> of a <div class="dialog message"> left in the template which seem to be
> related to holds.
> 
> Shouldn't these cases be covered too?

I don't believe it's necessary. I do see the "Hold needing transfer found" one, but I cannot figure out how to even trigger it. I wonder if it's just dead code. In any case, this patch won't impede the ability to see and act on those messages and we can follow this up with future bugs to take care of those as necessary. If there is a specific message you see needing taken care of let me know!
Comment 47 Koha Team University Lyon 3 2016-06-01 09:01:00 UTC
work as descibe
Comment 48 Nicole C. Engard 2016-06-02 15:26:18 UTC
Does that mean you sign off on this patch? If so please go ahead and submit a sign off.

Nicole
Comment 49 Biblibre Sandboxes 2016-06-02 16:19:18 UTC
Patch tested with a sandbox, by Christopher Brannon <cbrannon@cdalibrary.org>
Comment 50 Biblibre Sandboxes 2016-06-02 16:19:45 UTC Comment hidden (obsolete)
Comment 51 Jonathan Druart 2016-06-07 16:08:51 UTC
CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt
Comment 52 Nick Clemens 2016-07-07 20:17:58 UTC Comment hidden (obsolete)
Comment 53 Katrin Fischer 2016-07-11 21:28:02 UTC
Long read... and I have also tested this a bit:

1) Please make the buttons use the standard styling. - The current colors don't work with our green/grey/blue scheme.
2) I'd add a line break between the heading and the title - currently, the title can't be very long without breaking and it obscures the heading, which is what you should be able to focus on easily.

Testing "Hold found (item is already waiting)" - 
3) I don't think the "cancel hold" button should be the very first. What do you think? It's currently in the middle. My feeling goes towards: Confirm, Print and confirm, Cancel hold

Testing "Hold found"
4) The buttons don't look nice breaking over 2 lines (ok, not a blocker... but...)

I am changing this to enh, because I feel this is a bigger change now about the look and feel, that might be better in a stable version. Please let me know, if you disagree.

I like the new address layout without the bullet points!

BTW - do we need to repeat all that code for those 2 similar cases? (sep bug..)
Comment 54 Kyle M Hall 2016-07-20 15:59:39 UTC Comment hidden (obsolete)
Comment 55 Kyle M Hall 2016-07-20 16:01:02 UTC
(In reply to Katrin Fischer from comment #53)
> Long read... and I have also tested this a bit:

I believe this followup should take care of your concerns! We can't do much about the buttons breaking over two lines. I believe that's just the way Bootstrap deals with it.
Comment 56 Jonathan Druart 2016-07-25 13:46:47 UTC
(In reply to Katrin Fischer from comment #53)

Everything looks good to me (you will need bug 16942 to test this patch).

> BTW - do we need to repeat all that code for those 2 similar cases? (sep
> bug..)

Existed before this patch, but yes it would be nice to refactor stuffs.
Comment 57 Jonathan Druart 2016-07-25 13:47:44 UTC
Created attachment 53685 [details] [review]
Bug 11360 - Disable barcode field and submit button when a hold is found

At the moment when scanning in returns, it can be easy to miss a hold
trap due to the fact that the barcode and submit are still active and
the barcode field is focused on. A librarian who is focused on scanning
can easily scan another item and pass over the form, which is equivalent
to clicking the "ignore" button.

Test Plan:
1) Apply this patch
2) Trap a hold, note the new modal
3) Check the hold in a second time
4) Note the new modal
5) For each modal, test each button

Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Comment 58 Jonathan Druart 2016-07-25 13:47:48 UTC
Created attachment 53686 [details] [review]
Bug 11360 [QA Followup] - Fix styles and button order

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Comment 59 Kyle M Hall 2016-07-26 14:35:49 UTC
(In reply to Jonathan Druart from comment #58)
> Created attachment 53686 [details] [review] [review]
> Bug 11360 [QA Followup] - Fix styles and button order
> 
> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Jonathan did you intend to pass qa on this patch set, or did you just add an additional sign-off?
Comment 60 Jonathan Druart 2016-08-01 10:49:43 UTC
(In reply to Kyle M Hall from comment #59)
> (In reply to Jonathan Druart from comment #58)
> > Created attachment 53686 [details] [review] [review] [review]
> > Bug 11360 [QA Followup] - Fix styles and button order
> > 
> > Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
> 
> Jonathan did you intend to pass qa on this patch set, or did you just add an
> additional sign-off?

I wanted to let Katrin to have another look, but she told me it's ok if I PQA it.
Comment 61 Katrin Fischer 2016-08-01 21:33:25 UTC
Just took another look - agree with Jonathan!
Comment 62 Kyle M Hall 2016-09-02 17:20:32 UTC
Pushed to master for 16.11!
Comment 63 Katrin Fischer 2017-01-04 10:02:10 UTC
*** Bug 6392 has been marked as a duplicate of this bug. ***
Comment 64 Mason James 2017-05-24 00:50:09 UTC
Enhancement, skipping for 16.05.x
Comment 65 Owen Leonard 2017-11-09 17:00:05 UTC
*** Bug 11899 has been marked as a duplicate of this bug. ***