V3.9 support for legacy rules.nools.js

Hi everyone
I was wondering if CHT core v3.9 supports legacy rules.nools.js ?. The release notes on 3.8 shares that one must ensure schema changes are deployed but the link to that is broken. Was this removed ?

1 Like

Hey @atria.

All 3.x CHT versions (even up to 3.11) continue to support the rules.nools.js code. That link is for a private (internal) repository, sorry about that! We will fix it.

In the meantime, here is a relevant link for Living Good’s required schema changes. I believe you have access to that?

In case you don’t, or for other external users who don’t have access to that repository – here is a summary of the changes. There are only additions to the standard “rules.nools.js” template that is commonly used (including by most apps I’ve seen from LG). In the below blockquotes, I’ve added // THIS LINE IS NEW where changes are required.

define Target {
_id: null,
contact: null, // THIS LINE IS NEW
deleted: null,
type: null,
pass: null,
date: null

define Task {
_id: null,
deleted: null,
doc: null,
contact: null,
icon: null,
date: null,
readyStart: null, // THIS LINE IS NEW
readyEnd: null, // THIS LINE IS NEW
title: null,
fields: null,
resolved: null,
priority: null,
priorityLabel: null,
reports: null,
actions: null

return new Task({
_id: contact.contact._id + ‘-’ + schedule.id,
deleted: (contact.contact ? contact.contact.deleted : false) || (report ? report.deleted : false),
doc: contact,
contact: contact.contact,
icon: schedule.icon,
priority: schedule.description ? ‘high’ : null,
priorityLabel: schedule.description ? schedule.description : ‘’,
date: null,
readyStart: schedule.start, // THIS LINE IS NEW
readyEnd: schedule.end, // THIS LINE IS NEW
title: schedule.title,
resolved: false,

return new Target({
_id: report._id + ‘-’ + type + ‘-’ + index,
contact: c.contact, // THIS LINE IS NEW
deleted: !!report.deleted,
type: type,
pass: pass,
date: report.reported_date

The move to v3.8 is mostly smooth for those using the declarative configuration systems, but since nools.rules.js is very “free-form” there may be some scenarios that are more negatively affected by the upgrade. I recommend testing the system well before upgrading. Ensure that you are familiar with the breaking changes which happened in that version and hit us up with any questions.


Hey @kenn thank you for the feedback, It’s helpful and No, I don’t have access to This Repo - could i get it ?

Another question what medic-conf/cht-conf version would you recommend using with the required schema changes? I tried an install of medic-conf 3.1.0 but ran into some issues as shared in the screenshot, would you know why this is happening(tried a few hacks but got the same issues)

The attached image below is config error on /usr/lib/node_modules/medic-conf/src/bin/medic-conf.js:8

and this is my Dockerfile

Sorry - I meant to send this link: https://github.com/medic/config-lg/commit/b3cafcf7e8ec16ecb51109d199e57ee69e59ef6b. I cannot grant access to medic-projects but I believe you have permissions to this config-lg repo. Can you see that commit?

cht-core v3.8 requires >= medic-conf v3.1 - so the version you’re trying should work. But i’d recommend using the latest version of medic-conf - it works with core v3.8.

What version of node is running in your system? If I run medic-conf using node 6 I see the error you are seeing Unexpected token (. Can you try using >= node v8.10 which is the minimum supported version of node.

Thanks @kenn this is helpful, Yes am able to see the commit and made the adjustments on rules.nools.js that worked but my contact summary returns an error “Parsing error: ‘return’ outside of function” as shown in the screenshot

I went through the commit shared previously and the contact-summary seems identical which makes me ask were there configurations made to eslint-loader to make this disable this error ?

Note: Just to point out one thing the Dockerfile sets up node(3.0.0) causing this issue, maybe it should be updated to install a higher version of node as required.

Looks like you’re upgrading from medic-conf 2.x to medic-conf >= 3.x. If so, that error is probably this breaking change in medic-conf 3.0.

It is possible to upgrade both cht-core and medic-conf at the same time – but you might consider breaking this in two steps:

  1. Upgrade medic-conf upgrade to latest (continue to use your existing cht-core version).
  2. Upgrade cht-core

But basically, your contact-summary.js file has a line that says return blah; and you need to change that to module.exports = blah;. This was an update to leverage existing JavaScrpt standards and makes unit testing more accessible. The contact-summary should behave the same.

Thanks @kenn , I made all the necessary changes → followed the steps you recommended, thought i got to the finish line ^^, but cht-core(v.9) would not load contacts anymore because of something to do with

“Cannot assign to read only property ‘exports’ of object”

I did abit of research and found that this error is mainly from trying to use commonjs while i need to use
ESmodules but my exports and imports take the format of

const myfunction = () => {}
export default myfunction

import myfunction from './myfunction'

not sure what am doing wrong at this point ?, but any leads would be appreciated.

  1. Configuration error in contact-summary function: Cannot assign to read only property ‘exports’ of object ‘#’
  2. Error selecting contact Error: Configuration error
    at inbox.js?_sw-precache=2d544ea5c98cd434a65e863b87b45a56:3
    at inbox.js?_sw-precache=2d544ea5c98cd434a65e863b87b45a56:3
    at inbox.js?_sw-precache=2d544ea5c98cd434a65e863b87b45a56:3
    at c.$digest (inbox.js?_sw-precache=2d544ea5c98cd434a65e863b87b45a56:3)
    at inbox.js?_sw-precache=2d544ea5c98cd434a65e863b87b45a56:3
    at Object.completeTask (inbox.js?_sw-precache=2d544ea5c98cd434a65e863b87b45a56:3)
  3. inbox.js?_sw-precache=2d544ea5c98cd434a65e863b87b45a56:3 Failed to load tasks for contact TypeError: Cannot read property ‘children’ of null

Okay the solution was in Breaking Change - Modules like you shared

so basically
module.exports = blah;
and calling blah using
var blah = require('./blah.js');
thanks @kenn

That’s great @atria. Happy to hear your issue is resolved