COMMAND LINE INTERFACE

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

createSiteAdmin

Create a site admin user

COMMAND:

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.

ARGUMENTS:

email

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

organisation

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

password

The user’s password

EXAMPLE

migrateMongo

Runs any outstanding migrations on the Mongo database

COMMAND:

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.

ARGUMENTS:

-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.

EXAMPLE

Apply all outstanding migrations:

Roll back the last applied migration:

clearAggregationCache

Clear the cache of any aggregation data

COMMAND

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.

ARGUMENTS

-o --org <organisation_id> (OPTIONAL)

An organisation’s Mongo ObjectId.

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

EXAMPLE

Clear all caches:

Clear a particular organisation’s cache:

batchJobs

Batch run the worker across existing statements

COMMAND

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.

ARGUMENTS

-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.

EXAMPLE

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

updateStatementCount

Recalculates the statement counts on stores

COMMAND:

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.