Fixed fields are required to have all positions entered.

[Steve Callender]

For example, the Ill fixed field has 4 positions, so if just an 'a' is entered, it will not save with the record since not all 4 positions are accounted for. Instead you must enter 'a ' in order for it to save. This is a request to make the trailing spaces automatic in fields that have more than one position allowed in them.

[Robert J Jackson (rjackson-deactivatedaccount)]

I think that our libraries could live with the current functionality requiring full field entry - IF they were alerted to a non-save condition instead of no message as is the case at this time. The interface appears to be saving the data as it is now, but a subsequent query of the record shows no changes.

[Sarah Childs (sarahc)]

Right now catalogers in our consortia are either:

a)Not noticing, which causes errors in the MARC,
b)Noticing and not knowing how to fix the problem, and getting frustrated,
c)Noticing and knowing how to fix it, but still getting frustrated because prior to the upgrade to 2.0, we didn't have to fill in the spaces

A non-save condition notification would need to explain that the spaces need to be filled in, or it would only fix a. Even then, it wouldn't fix c. We probably could have lived with it like this if it had always been that way, but since it seems like a step backward, it feels really annoying.

And yes, we've shared the information that the spaces must be filled in, but people don't always listen, read emails, understand, etc.

[Elaine Hardy (ehardy)]

We would like to see a bug fix on this fairly quickly. I consider it a fairly serious bug since it has implications in database processing if the 008 is incorrectly edited, particularly if catalogers use the standard 008 to edit and miscount spaces.

As Sarah says, this feels like a step backward; one that will get easily overlooked since we are not accustomed to doing it.

[Tanya Prokrym (tanya-prokrym-deactivatedaccount)]

I would like to add my comments as well. This is a fairly serious bug for us. As Sarah stated earlier, our people are finding this really annoying and some of them assume fields are being saved, without re-checking or noticing. This has implications for not only cataloging but reporting as well.

[Mike Rylander (mrylander)]

I have a fix for this ready for testing. Anyone feeling lucky?

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/pad-fixed-fields

[Lebbeous Fogle-Weekley (lebbeous)]

While I don't fully appreciate how catalogers do it in practice, if I create a new record with the stock K_book template, fill in 100 ‡a, 245 ‡a, then type 'a' into Ills and click Save Record, no 'a' makes it into Ills' place in the 008.

If I do things in different orders, like tabbing out of the Ills field and then entering things in the regular numbered fields, sometimes it does work (the 'a' gets saved). Seems inconsistent though.

[Mike Rylander (mrylander)]

That is caused, I'm pretty certain, by the early-exit logic inserted by tsbere to avoid the field losing focus. I've force-pushed a change (untested) that should fix what you saw, Lebbeous, and address Thomas' original concern.

[Thomas Berezansky (tsbere)]

The updated version appears to have issues with multi-character fields, like Lang. I can't seem to get "eng" into it, for example, without a lot of micro-management of input (select each space individually, replace with character, repeat). If I try and just type "eng" then each keypress causes the entire field to be selected, overwriting previous attempts.

[Mike Rylander (mrylander)]

Thanks for testing, Thomas. The problem is that the short-circuit that this change removes we don't see an update of the field until you have entered as many characters as the field can take. So, obviously this is not the solution, but the previous behavior is a part of the problem and need to be removed.

UPDATE: another attempt has been force-pushed to the branch which uses onblur instead of oninput to void focus churn.

[Thomas Berezansky (tsbere)]

After multiple attempts at testing the newest version I can't seem to get it to update the MARC at all from the fixed fields editor. Try and edit, move to other fields or just tab out of the field I was editing, and it bounces right back to what it was before.

It is like it is triggering a "re-populate the fixed fields area" *before* triggering the "update the marc with the new data" code.

[Lebbeous Fogle-Weekley (lebbeous)]

Since there's no working solution yet, removing the pullrequest tag.

[Simon Mai (simonmai)]

For this issue, I will give it a try here:
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/simonmai/fill_trailing_spaces_fixed_fields
Please check it !
Thanks.
Simon.

[Simon Mai (simonmai)]

Actually, our libs found out that the current MARC editor make them difficult to edit the data in fields that had data in it to have NO information (BLANK). To make it works, spaces must be added to take up that space - otherwise, it retains the old data (after saving record).
So I tried to fix it as the bug 1152235
But yes, Elaine and Jason, if this bug was fixed (maybe you can try my above working branch), I think the bug 1152235 will not be caused.
Thanks.
PS: I've asked our libs about this, but unluckily they've been taken vacation (Spring break) now. I will post their comments about this ASAP.

[AlexK (alex-kent)]

I'm inclined to think this bug should be fixed. I can see it causing some major frustration for catalogers. Fixing it will help protect the integrity of the record itself.

[Elaine Hardy (ehardy)]

Simon,

I will ask Chris Sharp about testing this. It will have to be after our upgrade next weekend, however.

Thanks!

[Simon Mai (simonmai)]

You're welcome, Elaine.
I just updated the MARC editor a little bit.
Here is the new working that I fixed for our libs:
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/simonmai/fill_spaces_fixed_fields_automatic
I think our libs will be so happy if this bug was fixed with the bug 1053074 for new versions
Thank you.

[Elaine Hardy (ehardy)]

Unfortunately we are likely not to be able to get this tested before we go live with 2.3 next weekend. We will test as soon as possible afterwards.

[Elaine Hardy (ehardy)]

Simon,

We tested the bug fix. While it does fix the immediate problem and I can edit the fixed field (ff) in the grid, unfortunately it makes the bib source not editable. I tested both on records where I edited the ff grid and on those I did not. I verified that the ff grid was not editable on our live server and that the bib source was. Then went back to the test server and confirmed that while the ff could be edited via the grid, the bib source could not be changed.

Any way to fix that introduced bug and still allow editing the ff in the grid?

Elaine Hardy

[Elaine Hardy (ehardy)]

Just discovered that not being able to edit the bib source may not be a by-product of the bug fix. I had tested it on the live server but am now wondering if it is a permission issue. Will update soon.

Elaine

[Chris Sharp (chrissharp123)]

Simon,

I caught a typo in your marcedit.xul patch:

+ <textbox id="Ctry_tb" context="clipboard" class="plain" name="Ctry" maxlength="3" size="3" onkeypress="if (!(event.altKey || event.ctrlKey || event.metaKey)) { oils_lock_page(); }" onbur="updateFixedFields(this);" onfocus="this.select();"/>

(from http://git.evergreen-ils.org/?p=working/Evergreen.git;a=blobdiff;f=Open-ILS/xul/staff_client/server/cat/marcedit.xul;h=f5f93c5cc791ad3950deed365b857527c6fb4836;hp=2fd96890efe6371d75860051f4320ff5e43e5b6c;hb=1a4d04defc41e8ca649335eb01b5dc41a966b372;hpb=cc7ed07e0517fe51e7354e36aec27a9d01bb39e9)

"onbur" should be "onblur" there.

Hope that's helpful,

Chris

[Simon Mai (simonmai)]

Oh, thanks for testing and suggestion.
I've been really busy with everything I've got going on right now. Hopefully I can finish those soon and be right back with these MARC editor bugs ASAP.
Regards,
Simon.

[Remington Steed (rjs7)]

I tested both Mike's and Simon's branches, and both seem to work equally well. I didn't experience Thomas's bug from comment #10. I will push a branch tomorrow, using mostly Mike's code.

[Remington Steed (rjs7)]

Here is my signoff branch, with short comments added to Mike's code (since it took me a while to understand). Simon's solution was much simpler, but it seemed safer to put the fix in the FixedField object like Mike did.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/rsteed/pad-fixed-fields

[Ben Shum (bshum)]

Thanks Remington, grabbed your signoff and pushed to master, rel_2_7, and rel_2_6.