Item does not link to Monograph Parts in Evergreen Reports Module

Bug #1228392 reported by Erica Rohlfs
84
This bug affects 17 people
Affects Status Importance Assigned to Milestone
Evergreen
Won't Fix
Medium
Unassigned
3.0
Won't Fix
Medium
Unassigned
3.1
Won't Fix
Medium
Unassigned
3.2
Won't Fix
Undecided
Unassigned

Bug Description

Evergreen Version 2.4.2

Currently within the Reports Module, under Item as the Source, it displays the Field Name Monograph Parts as a link. However, a link to monograph parts within the reporter does not exist.
As more libraries begin to use monograph parts, it would be great to see further development to add a more circuitous route to the parts information within the reporter.

Erica Rohlfs (erohlfs)
tags: removed: module
tags: removed: reports
Ben Shum (bshum)
Changed in evergreen:
importance: Undecided → Wishlist
status: New → Triaged
tags: added: reports
Changed in evergreen:
importance: Wishlist → Medium
Revision history for this message
Chris Sharp (chrissharp123) wrote :

This issue is still present in 2.9/master as of right now. From what I understand of the structure of fm_IDL.xml, this *should* work. Here's a snippet:

<class id="acp" controller="open-ils.cstore open-ils.pcrud" oils_obj:fieldmapper="asset::copy" oils_persist:tablename="asset.copy" reporter:core="true" reporter:label="Item">
        <fields oils_persist:primary="id" oils_persist:sequence="asset.copy_id_seq">
...
            <field reporter:label="Monograph Parts" name="parts" oils_persist:virtual="true" reporter:datatype="link"/>
---
        </fields>
        <links>
...
            <link field="parts" reltype="has_many" key="target_copy" map="part" class="acpm"/>
...
        </links>

The other links (aside from "Holds" and one of the stat_cat-related links) show up in the source tree.

Revision history for this message
Mike Rylander (mrylander) wrote :

Chris,

The existence of a non-empty map attribute causes the reporter logic to ignore the field for linking. Due to the complexity it causes, that was made a TODO in the template builder logic.

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

I was just trying to create a report on in transit copies and wanted to include the part information and ran into this. Would it work to copy what the Peer Record Maps and Peer Records entries do? I wonder if that was to bypass this reporter issue?

Add a <field> entry of

<field reporter:label="Monograph Parts Map" name="parts_map" oils_persist:virtual="true" reporter:datatype="link"/>

and for the <links>

<link field="parts_map" reltype="has_many" key="target_copy" map="" class="acpm"/>

I just tried that out and it did work. I was able to create a report on transits with a column that shows the part label. Is this an acceptable solution?

Thanks
Josh

Revision history for this message
Blake GH (bmagic) wrote :

Josh,

That worked for me! Would you like to push a patch? Should it replace the current Monograph Part column?

Revision history for this message
Blake GH (bmagic) wrote :

I created a branch:
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/blake/LP1228392_Item_does_not_link_to_Monograph_Parts_in_Evergreen_Reports_Module

This does not change the existing IDL columns or links but instead creates a new virtual column and a link to match. Just in case there is existing code or existing templates that make use of the IDL Monograph Part.

Revision history for this message
Blake GH (bmagic) wrote :

I learned the hard way that this patch will break cataloging! Do not apply. However, it does* fix the bug, LOL.

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

In the interest of incremental improvements, here is a simple fix we've been running for a year or two: just allow the mapped fields to show up without doing anything special. This does mean the user needs to "reach through" the map table themselves, but it works, at least for what we've needed it for.

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

If someone doesn't point out why this is a really bad idea, I am guessing we'd need a similar "fix" for the web-staff side (haven't looked yet).

Changed in evergreen:
milestone: none → 3.2-beta
no longer affects: evergreen/3.1
Changed in evergreen:
milestone: 3.2-beta → 3.1.3
Changed in evergreen:
milestone: 3.1.3 → 3.1.4
Changed in evergreen:
milestone: 3.1.4 → 3.1.5
Changed in evergreen:
milestone: 3.1.5 → 3.1.6
Changed in evergreen:
milestone: 3.1.6 → 3.2.0
status: Triaged → Confirmed
Changed in evergreen:
milestone: 3.2.0 → 3.2.1
Changed in evergreen:
milestone: 3.2.1 → 3.2.2
Revision history for this message
Jane Sandberg (sandbergja) wrote :

Dan, I don't think that a similar fix would be necessary for the web client. As far as I can tell, this bug does not affect the Web client. Here's a gif of me successfully creating a report including Monograph parts in the Web client. So, I am applying the fixedinwebby tag, and I think that we should *not* be targeting this to 3.2.2.

tags: added: fixedinwebby
tags: added: pullrequest
Changed in evergreen:
milestone: 3.2.2 → 3.2.3
Changed in evergreen:
milestone: 3.2.3 → 3.3-beta1
status: Confirmed → New
Changed in evergreen:
milestone: 3.3-beta1 → 3.3-rc
Revision history for this message
Tiffany Little (tslittle) wrote :

Marking as Won't Fix since it has the tag 'fixedinwebby'.

Changed in evergreen:
status: New → Won't Fix
Revision history for this message
Andrea Neiman (aneiman) wrote :

Also marking won't fix for 3.2 series

Remington Steed (rjs7)
Changed in evergreen:
milestone: 3.3-rc → none
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

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