| Field | Description | Source |
|---|---|---|
timestamp | Time of the log entry. | Automatic (Logger) |
level | Debug, info, warn or error depending on log method used. | Manual |
message | Concise, human-readable summary of the log entry. The Error message when logging errors. | Manual |
context | Which software component or class the log entry comes from. | Automatic (Child logger) |
codeOwner | The team responsible for this part of our backend architecture. | Automatic (Service, Endpoint, Resource) |
name | The Error name. | Automatic (Error) |
stack | The Error stack trace. | Automatic (Error) |
dd | Extra metadata provided by datadog agent. Includes env, service and version sub fields. | Automatic (Datadog) |
traceSid | Trace Session ID to correlate logs with users without exposing PII. | Automatic (Authentication) |
http | Information about outgoing requests and responses. May include these subfields: status_code, status_text and url. | Automatic (Enhanced Fetch) |
fetch.name | Name of the enhanced fetch integration. | Automatic (Enhanced Fetch) |
organizationSlug | Reference to a government organization which a log entry or error relates to. | Automatic (Enhanced Fetch) |
Authorising APIs Flow
| web | native | |
|---|---|---|
| Inactivity Lifetime | 20 minutes | 90 days |
| Absolute Lifetime | 8 hours | 1 year |
island.is app showing a red dot on the notification bell
example push notification
example email notification
# New Notification Setup Guide ### Prerequisites Your organisation needs to be already integrated into [Mailbox/Pósthólf](/products/postholf) ### Hnipp notification templates A Hnipp notification template is a reusable resource for sending notifications to users, the template is cross-channel, so the message stays the same across web/app, push and email. Title = 35 chars Body = 100 chars Internal body = 256 chars A Hnipp notification consists of: * **Title (35 chars)**: a short and simple descriptive text giving context * **External Body (100 chars)**: a required description that **must not** contain any sensitive/private information, can be seen in external clients like email and outside app notifications and in internal clients if Internal Body is not provided * **Internal Body (256 chars)**: an optional description that **might** contain sensitive/private information, can only be seen in internal clients behind login in website and app * **Click Action Url**: An optional universal link that sends the user into a deeper context are in web or app related to the message ### Hnipp template variables The templates are reusable, multi-lingual and can be injected with context specific variables, such as sender, recipient or context specific values example template ``` Title: Nýtt skjal á Ísland.is External Body: {{organization}} hefur sent þér nýtt skjal í pósthólfið þitt á Ísland.is Internal Body: {{organization}} hefur sent þér nýtt skjal: {{documentName}} Click Action Url: https://island.is/minarsidur/postholf/{{documentId}} ``` becomes: ``` Title: Nýtt skjal á Ísland.is External Body: Fjársýslan hefur sent þér nýtt skjal í pósthólfið þitt á Ísland.is Internal Body: Fjársýslan hefur sent þér nýtt skjal: 500.000 kr inneign tilbúin til útborgunar Click Action Url: https://island.is/minarsidur/postholf/some-unique-document-id ``` Note in the example how the **Internal Body** contains user specific information while the **External Body** does not. ### How to setup a new Hnipp notification template #### Create and publish Get in touch with a Stafrænt Ísland contact to create and publish a new Hnipp notification template in the CMS. #### Preview and test Preview and test the notification by sending a test message to a test user via [Mailbox/Pósthólf](/products/postholf)-API using the new hnipp notification template in the development environment.\ In the example request below the Hnipp notification template is referred via the **templateId** property and if the template uses dynamic arguments those are provided in the **templateArguments** property ``` POST /api/v1/notifications [ { "kennitala": "0000000000", "senderKennitala": "0000000000", "templateId": "HNIPP.EXAMPLE.TEMPLATE", "templateArguments": { "salutation": "Hello world!" }, "publicationDate": "2023-04-19T14:50:04.4545645+00:00" } ] ``` ### Verify Hnipp notification template message on all channels Once a test message is sent verify the following for all supported languages: * in-Website notification * message appears and looks correct under notification bell * clicking on the message performs the desired action * in-App notification * message appears and looks correct under notification bell * clicking on the message performs the desired action * Push notification * message is delivered and looks correct on the OS screen of a real test device\ \&#xNAN;*NB. Test with a real device for actual results. Preferably both iOS and Android* * clicking on the message opens the island.is app and performs the desired action * Email notification * message looks correct in an email sent to a test user's email client * clicking on the message opens the island.is website and performs the desired action ### Well done! Once a Hnipp notification template is set up and verified it is ready for mass-use on production. # Notifications service workflow overview ### Workflow overview The notification service receives a request to create a notification, the service processes the request and places it in a AWS SQS. #### Message processing A worker periodically requests notifications from the **AWS SQS** queue in batches of up to 10 messages. The worker handler fetches data needed to send out the notification, the template from Contentful and user specific information and tokens from the user profile service. Then proceeds to send the notification to the appropriate channel (e.g., push notification via Firebase Cloud Messaging, or email). ### Error Handling and Retries * **Retry Logic**:\ If a message fails during processing, the system automatically retries up to **three times**. * **Dead Letter Queue (DLQ)**:\ If a message fails after the maximum number of retries, it is moved to a **Dead Letter Queue**. Messages in the DLQ are not processed automatically and require **manual intervention** to reprocess. ### Debugging and monitoring * **Message Tracking**:\ Each message is assigned a unique `messageId`, which can be used to trace its lifecycle within the system. * **Logging**:\ Logs for message processing are available in **Datadog**. # Email notifications # Pósthólfið ## Getting started * Request access to the mailbox (í. Pósthólfið). You can apply for access to the mailbox at island.is' application site
Minimum authentication type/strength to open/view the document. The default is LOW.
LOW = User/pass
SUBSTANTIAL = Two factor authentication (User/Pass and additionally an SMS)
HIGH = Client Certificate
Indicates the file type, current supported types are "url", "pdf" and "html". Unsupported file types are still available for download but will not be displayed properly.
If fileType is not provided "pdf" is assumed.
Strength of authentication of the user/recipient of the document.
LOW = User/pass
SUBSTANTIAL = Two factor authentication (User/Pass and additionally SMS)
HIGH = Client Certificate
| type | data | Description | |
|---|---|---|---|
| file | - | Opens the document in a new tab | |
| url | string | A url |
| Environment | Tier | FQDN Template |
|---|---|---|
IS-DEV | Development | xroad-dev.<member's domain>.is |
IS-TEST | Testing / QA / UAT / Staging et.al. | xroad-test.<member's domain>.is |
IS | Production | xroad-prod1.<member's domain>.isxroad-prod2.<member's domain>.is |
Example email for registering a X-Road Security Server to Central
X-Road Network Architecture
| Component | IS | IS-TEST | IS-DEV |
|---|---|---|---|
| Central Server | 176.57.224.0/25 | 176.57.224.128/25 | 176.57.227.96/27 |
| Mgmt. Security Server | 176.57.224.0/25 | 176.57.224.128/25 | 176.57.227.96/27 |
| Central Monitoring Server | 34.252.193.131 | 34.253.108.248 | 3.250.245.108 |