Project

General

Profile

Actions

Feature #273

open

Epic #49: Implement user, groups and permissions management

Module identity

Feature #273: Module identity

Added by Bricklou 9 days ago. Updated 8 days ago.

Status:
Planned
Priority:
Normal
Assigned To:
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
(Total: 0:00 h)

Description

A module extends the platform itself, so the platform has to be sure it is talking to the module the operator installed and not to something else on the same machine, and recorded history has to show when a module acted on its own rather than on someone's behalf.

A module gets its identity from being installed, with nothing for an operator to copy or store, and its channel to the platform is protected. Work a module does on its own initiative, such as a scheduled task, is attributed to that module by name. A module is trusted at the level of any other installed software: it declares the permissions of its own namespace and its own actions are not second-guessed.


Rejection reason

Superseded by the rewritten epic #49


Subtasks 2 (2 open — 0 closed)

User Story #302: As an operator, I want the platform to be sure which module it is talking to, so that nothing else on the machine can pretend to be onePlannedBricklou

Actions
User Story #303: As an administrator, I want to see when a module acted on its own, so that automated changes are not attributed to nobodyPlannedBricklou

Actions
Actions

Also available in: PDF Atom