Look What I Found: Notifications and Field Names

[Chuck Tomasi]

Short answer: Don't name your fields (in scoped apps) 'event'. It will come back to haunt you in notifications.

Background:

I was making a demo app. I extended task to a scoped table called x_meetup_event. From there I created a m2m table with sys_user (x_meetup_m2m_invite). This table basically has two fields user (reference to sys_user) and event (reference to x_meetup_event.)

As records are added the table, my plan was to trigger a scriptless notification with details about the event by dot walking through the event field, for example:

Event name: ${event.short_description}

Start time: ${event.work_start}

It took me a while to figure out why I wasn't getting any text next to the labels. After quite a bit of testing in the global scope and with other table names, it comes down to 'event' is a reserved word in notifications. Sure, now that I know, it all sounds so simple. The documentation mentions event.parm1 and event.parm2 are available in mail scripts, but the Notifications page says nothing about ${event}. This is one case where I appreciate the u_ prefix on tables and fields in the global scope.

You may run in to similar issues with fields named 'email', 'template', 'email_action', and 'current'. In general, stay away from naming fields the same as objects. If I were still in charge of the Technical Best Practices docs, I'd add this in there. Right martin.wood and enojardi?