Short 006/007/008 considered harmful

[Mike Rylander]

There are ways (many) where the 00X fields of a record may be saved without trailing spaces to pad out the correct length. This causes problems for the fixed field editor grid, which uses the substring() method to read and stitch together the data in the fixed fields. Specifically, if trailing space is truncated, both read and insertion can fail in annoying ways.

To fix this, we should always pad out the 00X fields to their appropriate lengths before reading or modifying them.

Branch coming soon ... WATCH THIS SPACE!

[Mike Rylander (mrylander)]

Branch available at: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/ff-pad-datafields

[Galen Charlton (gmc)]

Bumping up importance, as this is arguably a data-integrity bug.

[Galen Charlton (gmc)]

On reflection, setting back to low.

Note that while the 008 should be exactly 40 characters wide (for bib records) and the 006 exactly 17 characters wide, the length of the 007 varies depending on the first character. Also note that the convention is /not/ to retain trailing spaces in the 007 when saving the record; the padding should be understood to be a convenience for extracting values. It's OK to force 006 and 008 fields trailing padding when the record is saved, however.

On testing: the editor will throw "FIXME, MARC Editor, fillFixedFields: TypeError: result is undefined" alerts if the record lacks an 006 or 007 field. Removing pullrequest because of this.