Bug 30657 - Make patron attributes available via Template Toolkit in overdues
Summary: Make patron attributes available via Template Toolkit in overdues
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement with 10 votes (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords: Hackfest
Depends on:
Blocks: 15277 15278 36588
  Show dependency treegraph
 
Reported: 2022-04-29 15:08 UTC by Andrew Fuerste-Henry
Modified: 2024-05-08 06:43 UTC (History)
13 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2022-04-29 15:08:11 UTC
When using Template Toolkit to fetch patron values, one should be able to fetch patron attribute values. This would be useful both for printing those values into the notice content and for using those values in logic to vary the notices per patron.
Comment 1 Michael Adamyk 2022-05-03 14:56:34 UTC
+1
This would be great if it could be applied to all notices using Template Toolkit (particularly ISSUE and HOLD slips).
Comment 2 Katrin Fischer 2022-06-17 23:06:09 UTC
+1
Comment 3 George Williams (NEKLS) 2023-03-16 14:36:49 UTC
+1
Comment 4 Christopher Brannon 2023-03-16 17:18:29 UTC
+1 for sure!
Comment 5 Rebecca Coert 2023-10-10 16:59:54 UTC
+1
Comment 6 Barbara Johnson 2023-11-16 19:02:19 UTC
+1
Comment 7 Martin Renvoize 2024-03-08 10:20:53 UTC
There are already a couple of options here I believe.. but I think we should perhaps make it simpler/clearer.

You can use all accessors available from the Koha::Patron object assuming you've been passed said object into the template.

We have a few different attribute accessors:

* 'extended_attributes' which returns a resultset of attached extended attributes
* 'get_extended_attribute(code)' which returns the attribute associated with the code passed (but doesn't work properly for repeatable attributes)

To use those in TT:

*  [% FOREACH extendedattribute IN patron.extended_attributes %]
        <li class="patronattribute">
            <span class="patronattributelabel">[% extendedattribute.type.description | html %]</span>: [% extendedattribute.description | html %]
        </li>
    [% END %]

* [% SET attribute = patron.get_extended_attribute('code') %]
  [% attribute.description | html %]

The second one is clearly simpler to use, but only works for non-repeatable attributes so you need to know a little about the underlying patron data setup.  I also think it's a get wordy 'get_' and would prefer, I think, to have a simple 'extended_attribute($code)' accessor.
Comment 8 Martin Renvoize 2024-03-08 10:33:11 UTC
Annoyingly the extended_attributes accessor is also set to be a setter which means it won't pass through any filters you want to pass.. we should really rectify that.

In my opinion we should have two simple accessors that both accept standard dbic query filters.

* extended_attributes($where, $attr);
* extended_attribute($where,$attr);

We wrap our DBIx::Clas objects and thus remove the nice easy scalar handling of _rs on accessors which means we also have to deal with that in 'clever' ways at the TT level.. I can't remember the details for that off the top of my head though.

We really need to document all this better somewhere in short.
Comment 9 Katrin Fischer 2024-03-08 16:34:50 UTC
> In my opinion we should have two simple accessors that both accept standard
> dbic query filters.
> 
> * extended_attributes($where, $attr);
> * extended_attribute($where,$attr);

I like the look of this and I think you have made a very good point to make it easier to use. This will help people creating notices, but also be generally useful.
In your example code: $attr would be the attribute code. What is $where here?
Comment 10 Martin Renvoize 2024-03-08 16:43:59 UTC
Sorry, I wasn't clear with what those parameters meant.   They're a fairly standard pair of names for dbix query parameters.. i.e where is the SQL abstract where "field => value", then attr is other conditions like joins.

But that give perhaps more complication than end users in notices want..  it's a balance between simplicity and functionality.
Comment 11 Lucas Gass 2024-04-24 15:09:54 UTC
A real world example I had to cook up for a HOLD_SLIP:

[% SET alt_id = '' %]
[% FOREACH ba IN borrower.extended_attributes %]
     [% IF ba.code == 'UNCLE' %]
              [% alt_id = ba.attribute %]
     [% END %]
[% END %]

[% IF alt_id == 'BOB' %]
    Warning: Bob is your uncle.
[% ELSE %]
    Warning: Bob is NOT your uncle.
[% END %]


Would be nice to make it a bit easier.