Serial Items Tab and Note Fixes Needed

Bug #985227 reported by Dan Wells
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Undecided
Unassigned
2.1
Fix Released
Undecided
Unassigned
2.2
Fix Released
Undecided
Unassigned

Bug Description

Relevant branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/serial_items_and_note_fixes

This branch is for master and rel_2_2, and contains four commits of fixes for both the Items tab in the Serial Control interface and the various serial note editors. Since the commits are all dependent and related, I felt it best to make this a single bug.

The first commit is related to the notes tab, and changes the local structure of how item data for this tab is related to distribution and subscription data. In particular, distribution data is now fetched once rather than for every item row, which greatly improves both speed and data syncing issues.

The second through fourth commits are all related to minor note issues. They are separated based on functionality and also to help in backporting. (Note: none of these commits backport cleanly, so I will push the necessary backport branches (in progress) once this branch is merged). Highlights for these commits include:
  * Don't break when editing a note which contains XML reserved characters
  * Preserve and display newlines when entered in notes
  * Stop displaying notes in "random" (database) order
  * Prevent notes from being squashed and unreadable when many notes are present
  * Provide missing access points for launching the serials notes viewer from the item tab

Tags: pullrequest
Revision history for this message
Lebbeous Fogle-Weekley (lebbeous) wrote :

Thanks Dan,

This tests nicely, all five highlights.

Here's a squashed and signed off version.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/senator/serial_items_and_note_fixes

If you prefer the individual commits to go into master in a not-so-squashed form, I can do that too. Just let me know.

Revision history for this message
Dan Wells (dbw2) wrote :

Here is a rel_2_1 friendly version of the applicable commits (just 2 of the 4):

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/limit_excess_serial_data_rel_2_1

The commits are:
d17804f6b774198fd96b26c7f99b683002f9eb92
cbc50be33b0804424909d7ecb02fcc3e702e7de8

After looking at backporting to rel_2_0, I think the bang-for-buck just isn't there for that branch, so removing that target.

Thanks,
Dan

no longer affects: evergreen/2.0
Revision history for this message
Dan Scott (denials) wrote :

Many thanks Dan! I've pushed your rel_2_1 commits to rel_2_1.

(Aside: oy vey, we have some serious i18n work to do in serials to remove hard-coded strings... maybe for 2.3...)

Revision history for this message
Dan Scott (denials) wrote :

(I should note that the commits appear to have gone into master in 022b4952fb2414 and 536805361 without a reviewer's signoff, so in any case I'm changing the status of "master" in this bug to "Fix committed").

Changed in evergreen:
status: New → Fix Committed
Revision history for this message
Dan Wells (dbw2) wrote :

Thanks Dan. The commits in master were signed-off and pushed by Lebbeous, but I'm not sure how one can determine that easily in Git. I asked him if he could keep the commits separate, and he did so by merging the branch, which seems like the right solution to me, but it means his sign-off is only on the merge commit:

http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4d517fbbdf32fe205d47f7c7f9c0ff6954833773

I realize this wasn't really the point of your comment, and I'm certainly no master in Git (so there might be a simple answer), but maybe we need to discuss as a group if merge commit sign-offs are sufficient, or if we need to agree to handle multi-commit sign-offs some other way?

I'll also bring this up on list or in a meeting (unless someone has this figured out already and responds).

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.