CLI Operations


Learning Locker comes with a range of CLI commands that can be used to execute common administrative tasks.

Note: In order to use the CLI commands, you must ensure that the CLI server is built. The default install script will have performed this action as part of the yarn build-all command, but it can manually be built using yarn build-cli-server

Note: These commands should be run from the Learning Locker working directory. By default, with the install script, this is /usr/local/learninglocker/current/webapp


Create a site admin user


1 node cli/dist/server createSiteAdmin [email] [organisation] [password]

Create a new user and organisation for the site. This user will have the Super User privilege (only assignable via this command) and will also automatically be made an admin of the new organisation.

Additional organisation admins can be made within the platform but other super users need to be made via subsequent calls to this command.



The email of the user - this is what they will use to login


The name of the new organisation. If the organisation already exists, the new user will be added to it.


The user’s password


1 node cli/dist/server createSiteAdmin "" "Example" "password123"


Runs any outstanding migrations on the Mongo database


1 node cli/dist/server migrateMongo

Will check for any migrations that have not been run and apply them to the database. You can run migrations “up” or “down”. The former will apply migrations, whilst the latter will roll back migrations.

If you do not pass any arguments, defaults to -u; all pending migrations will be performed.


-u, --up [target]

Runs all pending migrations.

The optional [target] parameter can be passed to specify a certain migration to run. Pass next as [target] to run only the next pending migration, or the name of a certain pending migration to run only that one.

-d, --down [target]

Optional. Runs applied migrations down until the migration name specified as [target]. Also accepts last as [target] to only down the last applied migration.

-i, --info [level]

Display the state of migrations (which have been run, which haven’t). Can optionally specify v or verbose as [level] to output more detailed information.


Apply all outstanding migrations:

1 node cli/dist/server migrateMongo --up

Roll back the last applied migration:

1 node cli/dist/server migrateMongo --down last


Clear the cache of any aggregation data


1 node cli/dist/server clearAggregationCache

Will clear down any cached aggregation results. This can be useful if you require an up-to-date result for a particular visualisation or query.


-o --org <organisation_id> (OPTIONAL)

An organisation’s Mongo ObjectId.

Filter to only clear down the cache for a particular organisation.


Clear all caches:

1 node cli/dist/server clearAggregationCache

Clear a particular organisation’s cache:

1 node cli/dist/server clearAggregationCache 572cac001bb110583ed76177


Batch run the worker across existing statements


1 node cli/dist/server batchJobs

Will force statements back through the respective worker queue if they have not already been handled. This is useful if you have migrated statements into the LRS (e.g. if migrating from v1), or if your workers were not enabled at the time your statements were inserted into the LRS.

Note this can be an intensive task and may be best done on a separate box.

Currently you can batch process the Query Builder Cache generation (used to populate the items for the query builder) and also the persona generation.

When a worker job is completed, the appropriate worker queue name will be populated into the completedQueues array on each statement document in the database. If you wish to reprocess a set of statements, then clearing the completedQueues will allow you to reprocess them.


-j --job [job] (OPTIONAL)

Which worker job to run. querybuildercache* and personas.

  • Default job

-o --org [organisation_id] (OPTIONAL)

An organisation’s Mongo ObjectId.

Filter to operate on only statements in this organisation.

-l, --lrs [lrs] (OPTIONAL)

An LRS’s (store) Mongo ObjectId.

Filter to operate on only statements in this store.

-b, --batchSize [batchSize] (OPTIONAL)

How many statements to include in each batch. For query builder cache generation, good performance is seen with 1000 per batch. For persona processing we’ve seen good results with this set to 100.

-f, --from [date] (OPTIONAL)

ISO8601 formatted date to query the stored date from.

-t, --to [date] (OPTIONAL)

ISO8601 formatted date to query the stored date to.


Process persona data on all statements (100 per batch) personas in a particular store:

1 node cli/dist/server batchJobs -j personas -b 100 -lrs 572cac001bb110583ed76177


Recalculates the statement counts on stores


1 node cli/dist/server updateStatementCount

For each store, will count how many statements exist in the database and update the statementCount property on the store document. This may be required if statements have manually been deleted permanently from the database.

Note: as of v2.6.3 this process is done in synchronously per store to avoid large concurrency query issues on Learning Locker’s with many stores.

Learning Locker and the Squirrel logo are trademark of Learning Pool 2020 | Learning Locker is licensed under GPL 3.0.