Logbook - Extending¶

Privileges¶

These privileges control access to logbook operations:

Users without Logbook_Add will see the Add button area disabled and grayed out, with a red box overlay displaying a message indicating the required privilege. The Enabled property on the button is bound to scUsers.hasPriv("Logbook_Add"). The same pattern applies to the other logbook privileges.

The check always runs on the system where the logbook is open. Writing to a remote system's logbook is therefore governed by the local user's privileges, not by the remote system's. See Writing to a remote system's logbook.

Topic Storage¶

An entry's placement is held in three columns on the logbook table. topic_kind and topic_ref are added on start if the table predates them, so an existing project upgrades itself.

The derivation takes the longest part of the path that resolves to a known view or tag, and keeps whatever follows as the entry's own sub-path. MB/AS02/Station2/GT44/Trend therefore anchors to the sensor MB.AS02.Station2_GT44 and keeps Trend as a node beneath it.

Self-healing on start¶

reconcileTopicRefs() runs once on start and re-derives the anchor of every distinct topic. This keeps placements correct after views are renamed or moved, and after the object index is rebuilt.

Archiving¶

Archiving has replaced per-entry deletion. There is no function that deletes a single entry, and no view offers one. An entry is archived instead, which hides it from the list while keeping it in the database. It is stored in the archived column on the logbook table, which is added on start if the table predates it.

Archived entries are excluded from the topic tree and from the user list in the filter, so a topic whose entries are all archived disappears from the tree until archived entries are shown.

A handler exposes showArchived, which defaults to false. Setting it to true before calling load() includes archived entries in the list.

Retired soft-delete¶

An earlier deleteMark column implemented a separate soft-delete lifecycle. It has been retired in favour of archived. On start, any rows still marked deleteMark=1 are deleted and the column is dropped. No manual migration is needed.

Script Reference¶

The scLogBook script resolves placements and builds the tree. A view holds a handler instance, created with new scLogBook.logBookHandler(topic, view), which owns the entry list and the tree for that view.

Tree keying¶

The operator's choice is held in the LogBookTreeDirMode Data Store point, which every logbook view watches with a DataStoreListener. The point is not persisted, so the tree returns to workview mode when the application restarts.

Resolution¶

Opening a logbook scoped to something¶

A view or a button opens a scoped logbook by naming the topic to select, then linking to the logbook pop-out. The topic is handed over in app.logbookSelectedTopic and consumed by the pop-out:

app.logbookSelectedTopic = scLogBook.normalizeTopic(this.view.name);
app.popOut.setView("Pop_Outs/LogBookControls/GetLogBookEntryByTopic.kvie");
app.popOutVisible = true;

The pop-out resolves that path back to its anchor with resolveTopic(), records it with setScope(kind, ref), and calls applyScope() to translate the anchor into a path for whichever mode is active. Holding the scope as an anchor rather than as a path is what lets the selection survive a mode switch.

Systems¶

The tree and every query work against one system at a time: this one, or a remote system shown under its own top node. See Logbooks of Remote Systems.

A handler sets the active system before every database access, and a new handler starts on this system. A remote system's view index cannot be built by scanning its view folders, so it is read from that system's object index and from the views its notes are filed on.