Display issue with MARC view

Bug #1843637 reported by Elaine Hardy
82
This bug affects 18 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Low
Unassigned
3.2
Fix Released
Low
Unassigned
3.3
Fix Released
Low
Unassigned

Bug Description

In 3.2.3 MARC view has a display issue where the second indicator does not align properly when on MARC field is long enough to wrap to multiple lines.

See attached screen shot.

Revision history for this message
Elaine Hardy (ehardy) wrote :
Revision history for this message
Jennifer Pringle (jpringle-u) wrote :

This issue has recently started for us in both 3.1.7 and 3.3.3

Changed in evergreen:
status: New → Confirmed
Changed in evergreen:
assignee: nobody → Terran McCanna (tmccanna)
Changed in evergreen:
assignee: Terran McCanna (tmccanna) → nobody
tags: added: usability
Revision history for this message
Janet Schrader (jschrader) wrote :

Elaine, I can confirm that the second indicator does not align properly, but it is not because the field is long enough to wrap. At least in my system, it's only happening to fields that have a second indicator. A long 520 or 505 field with no second indicator is not affected. If I remove or add a second indicator the display changes regardless of the length of the field.

It could possibly be due to a Chrome update which may explain why it started happening around the same time in various networks. However, I looked at some of the affected records in Firefox and they also have the same problem. It is also not happening to all records. And when I print out a MARC view of the record it is okay.

Today I removed and re-added a 245 2nd indicator and tried zooming out and at 90% in Chrome the alignment became okay. In Firefox I had to go to 80%. But this only worked one time, other records I edited did not change regardless of how small I made the view, it was still bad.

It is not happening to the view of the MARC record in the OPAC even if I enlarge it to 150%. If the record is not affected in the first place, then enlarging the view does not affect the display.

As far as I can tell the box for the second indicator is a fixed width. If the cursor is in the box and you hit delete it expends but you can still only enter a single character. Even if you enter an invalid character it causes the misalignment. I think it has something to do with a character in the 2nd indicator box but can't figure out what that is.

Evergreen release 3.2.5
Chrome version 76.0.3809.100

Revision history for this message
Terran McCanna (tmccanna) wrote :

My stab at CSS changes is available here:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mccanna/lp1843637_marc_view_display

The MARC View in the web staff client should now align the content of each row at the top (see attached screenshot) for better readability. (See attached screenshot)

I also removed some deprecated "valign" tags and moved the existing in-line CSS to the cat.css file.

tags: added: pullrequest
Revision history for this message
Elaine Hardy (ehardy) wrote :

Janet -- One long field can throw many of the 2nd indicators off. If you shorten or remove the long field, all the indicators align.

Terran has hopefully fixed all the alignment problems, however.

Revision history for this message
Elaine Hardy (ehardy) wrote : Re: [Bug 1843637] Re: Display issue with MARC view

Opening a ticket for Chris to apply to test now. Thanks!

J. Elaine Hardy, PINES and Collaborative Projects Manager
------------------------------

Georgia Public Library Service

2872 Woodcock Blvd., Suite 250 | Atlanta, GA 30341

(404) 235-7128 | <email address hidden>

(404) 548-4241 | Cell

<https://www.facebook.com/georgialibraries>
<https://www.twitter.com/georgialibs>

Join our email list <http://georgialibraries.org/subscription> for stories
of Georgia libraries making an impact in our communities.

On Wed, Sep 11, 2019 at 6:30 PM Terran McCanna <
<email address hidden>> wrote:

> My stab at CSS changes is available here:
>
> https://git.evergreen-
>
> ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mccanna/lp1843637_marc_view_display
>
> The MARC View in the web staff client should now align the content of
> each row at the top (see attached screenshot) for better readability.
> (See attached screenshot)
>
> I also removed some deprecated "valign" tags and moved the existing in-
> line CSS to the cat.css file.
>
>
>
> ** Attachment added: "updated-marc-view.JPG"
>
> https://bugs.launchpad.net/evergreen/+bug/1843637/+attachment/5288162/+files/updated-marc-view.JPG
>
> ** Tags added: pullrequest
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1843637
>
> Title:
> Display issue with MARC view
>
> Status in Evergreen:
> Confirmed
>
> Bug description:
> In 3.2.3 MARC view has a display issue where the second indicator does
> not align properly when on MARC field is long enough to wrap to
> multiple lines.
>
> See attached screen shot.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1843637/+subscriptions
>

Revision history for this message
Janet Schrader (jschrader) wrote :

Thank you, Elaine. I really apologize. I was too stubborn to understand it.
I get it now. I added a long annotation to a record that didn't have one and got the misaligned indicators. I'll see if Jason can a patch to our training server. We're doing a lot of bug fixes in October and this would be a good one to include. One thing it did was let me know that there are some catalogers out there who do actually look at the MARC record.

Revision history for this message
Elaine Hardy (ehardy) wrote :

I apologize for sending an internal email here!

Testing the fix on our test server. The display has corrected for all the records I have checked to this point. Very nice!

Revision history for this message
Jason Stephenson (jstephenson) wrote :

I am merging Terrna's branch into 3.2.8 for testing on our training server at CW MARS, and I have a question.

Was the deletion of the two record-merge-container directives and record-edit-container directive in the CSS truly intentional? They are still referenced in the record bucket merge template: Open-ILS/src/templates/staff/cat/bucket/record/t_merge_records.tt2.

Revision history for this message
Terran McCanna (tmccanna) wrote :

No, I didn't intend to delete those! Thanks for catching that, Jason!!!

Revision history for this message
Terran McCanna (tmccanna) wrote :

I won't have a chance to rebase until next week when I'm in the office, but will plan to do so then.

tags: added: needsrepatch
Changed in evergreen:
assignee: nobody → Terran McCanna (tmccanna)
Revision history for this message
Kathryn Riedener (kriedener) wrote :

I don't know if this screenshot is helpful, but when printing the MARC View, it displays periods following the second indicators

Revision history for this message
Elaine Hardy (ehardy) wrote :

I think Terran fixed that as well

Revision history for this message
Terran McCanna (tmccanna) wrote :

Okay, one more try:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mccanna/lp1843636_marc_view_display

(And yes, I took out that stray period while I was at it since it didn't seem to serve any purpose.)

tags: removed: needsrepatch
Changed in evergreen:
assignee: Terran McCanna (tmccanna) → nobody
Revision history for this message
Chris Sharp (chrissharp123) wrote :

Works for me. Pushed to master, rel_3_2, and rel_3_3. Thanks, Terran!

Changed in evergreen:
status: Confirmed → Fix Committed
milestone: none → 3.4-beta2
Galen Charlton (gmc)
Changed in evergreen:
importance: Undecided → Low
Galen Charlton (gmc)
Changed in evergreen:
status: Fix Committed → Fix Released
milestone: 3.4-beta2 → 3.4-rc
status: Fix Released → Fix Committed
Galen Charlton (gmc)
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.