Reports, reminders, settings records and multi-select fields
Part 3 of 7 · 7. Manifests
Back: The extension points' kindsNext: Register books, limited fields and your Desk page
- A report's columns from one table of the record. A column or a filter may name
table.field(items.qtyon a stock count lists one line per item row, with the count's own columns repeated on each). Name one table per report (two multiply each other's rows);order_byis one field of the record itself, withascordesc. With a totals row, leave out a number column of the record itself (it would be added once per line). The totals row adds the lines on screen and number fields only, so a read-only figure such as a count line's quantity difference stays blank there. A filter on the table lists a record once per matching row and leaves out a record with no rows. A report, a number card or a chart may name a field the same manifest adds: the install makes your fields first. A branch user sees every line of a record they may open, as its form shows them; a row field above their level is left out. In a report e-mailed on a schedule, a record column and a row column of the same name overwrite each other: give the report one of them. Desk opens a report sorted by the record type's default, not byorder_by. - A notification. It may use any event and any recipient by role or by a field of the record, on any record type: mail the buyer when a Purchase Order is submitted, with its print attached. On the till's own records it is only Days Before or Days After a date (
days_in_advance,date_changeda Date or Datetime field), because any other event runs inside the till's save. By e-mail or the bell, to the retailer's own people, never to an address the manifest names. Aconditioncompares the record's own fields with plain values, and the subject and message call nothing:{{ doc.⟨field⟩ }}. What iVendNext accepts for a date reminder, as for one set by hand in Desk: no cap (one message per record on the day); every holder of the role, in every store, receives every record; a template error skips one message, and an error outside it (a record deleted mid-run, a date field removed later) stops that day's run for every date notification on the site after it, the retailer's own included. A placeholder shows its field to every holder of the role, even a field at a level the role cannot see in Desk. - A notification's own print. A notification may attach a print of its record, on any record type: the record type's default print, or a print format named in
print_format(attach_print: 1). The attached print is rendered with no viewer's rights and mailed to the retailer's own people, so show the record's own fields (ivn_rowsandivn_valueread nothing in a mail). Keep Print Settings > Allow Print for Draft on (it is on by default): with it off, a draft's mail is dropped. - A multi-select field (
Table MultiSelect, Brands on Supplier): it points at one of your own child record types, which must have a Link field shown in the list ("in_list_view": 1), or Desk drops the rows at the save. A plain table loses its Desk rows the same way unless its child shows some field in the list. - A settings record (
"issingle": 1): one record, no list, as every settings screen of the product. Name it only where a record is read by its name: a property setter, a workspace shortcut that opens its form, a save rule'svalue_from_typeandvalue_from_name. A list, a report or a date notification on it reads a table it does not have. An update may not make a record type a settings record or stop it being one: ship a new one under a new name. A service reads it at/api/resource/⟨type⟩/⟨type⟩. - Uninstall also exports every row of your child record types wherever they hang (a multi-select on a large catalogue makes a large file), and a settings record as its one record.
Back: The extension points' kindsNext: Register books, limited fields and your Desk page