Bug 21165 - Notice Module governs fields available in letter.pl, but this often doesn't fit letter.code
Summary: Notice Module governs fields available in letter.pl, but this often doesn't f...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-06 20:58 UTC by Barton Chittenden
Modified: 2018-08-06 21:10 UTC (History)
0 users

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 Barton Chittenden 2018-08-06 20:58:37 UTC
When or updating a new notice in Home › Tools › Notices & Slips › Modify notice, staff can click on fields in the field list, then click 'Insert' and the field will appear at the cursor position in the message body. So, for example, when editing the 'DUEDGST' notice, one can select 'items.biblionumber', then click insert, and the text

<<items.biblionumber>>

will appear in the body of the message.

The problem is that the available fields are selected based on letter.module. In the case of 'DUEDGST', this will be circulation... and this does exactly the wrong thing, because most of the fields available (items.*, biblio.*, biblioitems.*, issue.s*) are *not* valid in DUEDGST -- only <<items.content>> <<count>> and branches.* are valid in that notice.

Also, there are things missing that *could* be there -- for instance <<today>> and <<count>>. Also, if we're going to use loops like

<items>
</items>

It should be possible to insert these from the list

As it stands, the field list is often misleading. If 'DUEDGST' *only* showed <<items.content>>, it would easier for educators to point to the field list and as a reference. As it stands, at best, they have to qualify its usage, and at worst, the list is actively misleading.

The list should probably be generated based on 'letter.code' -- the available codes are best read from the call to C4::Letters::GetPreparedLetter, especially the 'table' and 'repeat' hashrefs.

Also, as we go forward using template toolkit based notices, it would be great if snippits of template toolkit code were available as well.
Comment 1 Barton Chittenden 2018-08-06 21:05:22 UTC
I should note that the DUEDGST and PREDUEDGST are probably the worst offenders in terms of the available fields not fitting the notice; I think the circulation module is the broadest, but any category that has more than one letter code may have issues.