COMMAND LINE INTERFACE
Learning Locker comes with a range of CLI commands that can be used to execute common administrative tasks.
...
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:
| Code Block |
|---|
node cli/dist/server createSiteAdmin [email] [organisation] [password] |
...
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
| Code Block |
|---|
node cli/dist/server createSiteAdmin "user@example.com" "Example" "password123" |
...
migrateMongo
Runs any outstanding migrations on the Mongo database
COMMAND:
| Code Block |
|---|
node cli/dist/server migrateMongo |
...
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:
...
| Code Block |
|---|
node cli/dist/server migrateMongo --down last |
...
clearAggregationCache
Clear the cache of any aggregation data
COMMAND
| Code Block |
|---|
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.
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:
| Code Block |
|---|
node cli/dist/server clearAggregationCache |
...
| Code Block |
|---|
node cli/dist/server clearAggregationCache 572cac001bb110583ed76177 |
...
batchJobs
Batch run the worker across existing statements
COMMAND
| Code Block |
|---|
node cli/dist/server batchJobs |
...
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:
| Code Block |
|---|
node cli/dist/server batchJobs -j personas -b 100 -lrs 572cac001bb110583ed76177 |
updateStatementCount
Recalculates the statement counts on stores
COMMAND:
| Code Block |
|---|
node cli/dist/server updateStatementCount |
...