Skip to content
Open
Show file tree
Hide file tree
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 68 additions & 0 deletions documentation/PCPChannel.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
## The PCP Interface

This document describes how the __PCP Interface__ works and what its API is.

### Introduction
The PCP stands for the Personal Control Panel and can be considered the GPIIs main place for displaying messages to the user as well as providing the user with a place to adjust some of their settings, along with other useful controls

The PCP Interface can be connected to via the web socket: `http://localhost:8081/pcpChannel` and its API provide functionality for:
* Notifying when a user is logging in and logging out
* Sending a list of desired adjusters to the PCP
* Sending messages to be displayed in the PCP
* Receiving responses to messages from PCP

Message types:
(Info<- default), Error, Warning
{
type: "infoMessage",
message: {
dk: "Katte er nogle trælse kræ",
en: "Howdy user! This is a message to you",
es: "¿Hola Pedro, donde esta la biblioteca?"
}
}

### Internal API

The PCPChannel is a component of the Flowmanager, used in the local/hybrid deployment on the local device. Its 3 main invokers are:
* `sendUserMessage`: This will send a message to be displayed in the PCP and takes a 'message' and a 'messageType' argument.
* **message** Can be either an object with messages keyed by language code, e.g.: `{ "en": "My message", "es": "Mi mensaje"}`, or a simple string, which the system will assume is an english message wrap accordingly
* **messageType** (optional) should be either "infoMessage", "warningMessage" or "errorMessage" - and will default to "infoMessage" if no second argument is given.
* `notifyLogin`: Should be called when notifying the PCP of a new user login. It takes two arguments; userToken and adjusters:
* **userToken** should be the token of the user logging in
* **adjusters** (optional) An object of the adjusters to display as keys and the value to show for the given adjuster as value. Will default to `{ "http://registry.gpii.net/common/highContrastEnabled": false }`
* `notifyLogout`: Should be called when notifying the PCP of a user logout. Does not take any arguments

### External API


#### Connection

Connection to the PCP is done as a socket connection to the URL `/pcpChannel`.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WebSockets



#### On login [`login` signal]:

When a user logs into the system, it will emit a `login` signal. The body of this will be a JSON object with a key `userToken` for the userToken of the user logging in, and a `settings` key with the adjusters to be displayed. An example of a `settings` value is: `{ "http://registry.gpii.net/common/highContrastEnabled": false }`
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"it", I assume, meaning the channel. Should be clear in which directions these are emitted (in this case, I presume, from server to client). Also the standard name for this element is "message", not "signal".



#### On logout [`logout` signal]

When a user logs out of the system, it will emit a `logout` signal to the socket.


#### Sending user messages [`message` signal]

When the system has a message it will emit a `message` signal. It will have the format:

```
{
"type": "infoMessage",
"message": {
"en": "My message",
"es": "Mi mensaje"
}
}
```

Where the `"type"` can be either "infoMessage", "warningMessage" or "errorMessage", and `"message"` will contains messages keyed by language codes.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a question.
Why do we want to pass the messages in every language in the world? Can't we just either:

  • Let the PCP to translate the messages by itself
  • Send the message in the language that the PCP is currently using

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think it would be possible to have the PCP translate the message itself, as the messages could be anything - and hence we wont be able to have a fixed translation table in the PCP. I agree though, that for fixed and well known messages (eg. for the "try harder" stuff, and so on) we could keep the text (and translations) in the PCP.

in terms of the second option, that might be a good idea - I hadn't considered it.. I guess I've been assuming that it was the job of the PCP to detect the language (since right now it runs in browser), decide on the fallback language, etc... but this assumption might be wrong

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"language" should be a setting which we can determine from the user's preferences. It is, after all, our job to encode the user's preferences for UIs! It's not the PCP's job to detect the user's language, it is our job as the GPII - the browser's language is just one source of input, which, if we decided to listen to it, should be implemented as a settingsHandler in the usual way. In any case, Javi's original comment is correct - we should send the message in just the language which is appropriate.

10 changes: 9 additions & 1 deletion gpii/node_modules/flowManager/src/FlowManager.js

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

132 changes: 132 additions & 0 deletions gpii/node_modules/flowManager/src/PCPInterface.js

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

32 changes: 28 additions & 4 deletions gpii/node_modules/flowManager/src/UserLogin.js

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

18 changes: 14 additions & 4 deletions gpii/node_modules/flowManager/src/UserLogout.js

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Loading