Bug 2927 - Saving on enter
Summary: Saving on enter
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: Main
Hardware: All All
: P3 enhancement (vote)
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-26 03:04 UTC by Joann Ransom
Modified: 2015-02-12 21:28 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:04:24 UTC


---- Reported by jransom@library.org.nz 2009-01-26 15:04:47 ----

I would like to be able to save changes to a screen by hitting the enter button instead of having to scroll or tab right through the page to save my work.

Discussion carried out on koha list:

Q: " I'm not sure this would be a universally accepted change. Would anyone
else care to give their opinion?"

*A1. I'm not sure - isn't submit-on-enter usual for web apps?

*A1b. Sorta.  It is common for web forms except where: 1. textarea input might include line breaks as valid (for example this gmail interface I'm using right now), or 2. multiple submit buttons allow different options, or3. premature submission is particularly undesirable (large edits, generation of content, credit card transactions, etc). 

Some browsers implement "submit on enter" behavior when focus is in a given form where others do not.  I assume the way around this is via YUI and explicitly defined behavior where desired.

*A2. I always found annoying to have <enter> working sometimes, and sometimes
(most ?) not. I would be very happy to have a single behaviour. My preferred being <enter> working.

*A2b. Same for me.

*A3. We were using submit on enter with Acq and the processors do miss it now that it is gone. We had the barcode scanners programmed to add the enter and we would put the barcode of new items in last. Saved moving to the bottom of the page and clicking- Doesn't sound like much of a savings but when you are entering hundreds of books a day the time adds up.

*A4 This is an issue I've wrestled with elsewhere in Koha's interface:
places where scanning a barcode should *not* submit the form. In
particular, member entry and item entry, where it's likely that a
librarian will be using a barcode scannner to enter data. That's part
of the reason why I'm hesitating on whether or not enter should submit
by default.

*A4a Why not in those instances just make adding the barcode the last thing you do on the form?

*A4b Unfortunately this solution only works if you've only got one barcode
entry field. I know some libraries are scanning the library card both
under card number and something else--opac login maybe?

*A4c Doesn't the library need to programme each barcode reader to send an "enter" command? That should mean that they can control the behaviour? IE so that if they don't want the barcode reader to send an enter & submit the form, then they don't set them to do it?

*A4d That's true, but since the most often-used function of a barcode
scanner will be for checkouts and check-ins it's not practical to
eliminate the "enter" from the scanner. Even our catalogers spend a
fair amount of time checking in items since they help fulfill reserves
on newly-arrived items.

I hope I'm not coming off as being argumentative here, I'm just trying
lay out the pros and cons.

* A4e My oldest barcode reader here (PS/2 type) sends enter after a barcode
and it's not programmable.  It would be very good to have barcode as
the last field whenever possible and things like submitting a form
with too few barcodes to simply redisplay the form, but I think/hope
these old barcode readers are dying out in favour of USB HID ones, so
maybe it's a niche requirement.



---- Additional Comments From wizzyrea@gmail.com 2009-02-04 10:39:38 ----

I am for this. 

Also for putting barcode entry at the bottom of the page on new patron entry forms.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:04 UTC  ---

This bug was previously known as _bug_ 2927 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2927

Actual time not defined. Setting to 0.0

Comment 1 Paul A 2013-06-24 12:56:30 UTC
We are not against this - hitting <enter> prematurely does not appear to be "dangerous" as you can always "re-edit."

However, (I'm not trying to re-purpose this bug!) it would be good to move the *item* save button to top left above data input for consistency with biblio records.  -- Paul