Configure order options

Notify all signers

Errand signers can be divided into solicitors and signers, where solicitors creates the errand and the signers signs the errand (a solicitor can also be a signer). Only the solicitor can download the document after completion and will be notified on the status. However, the notifyAllSigners functionality gives the solicitor an option to extend this permission to the signers, so that everyone in the errand can download the document and will be notified on the status.

If activated, a new checkbox will appear in the options section when selecting signers. Selecting the checkbox will activate notifications to all selected signers. If the checkbox was selected it will also be displayed in the overview section of the order.

This setting is set on errand level, meaning solicitors can not enable download to only some signers.

Usage

This is the configuration parameters that should be added the the config/config.json file:

"orderOptions": {
  "enableNotifyAllSignersOption": true | false,
  "defaultSignerNotification": true | false
}
  • enableNotifyAllSignersOption - Whether or not this functionality should be enabled to the user. If disabled, only solicitors will be able to download the document
  • defaultSignerNotification - Default setting. If true, all signers will be able to download, and get status notification of, the document. If false, only the solicitor will be able to download the document. Regardless of default setting, solicitors can override it via the UI by checking/unchecking the checkbox.

Invite URL target (formerly linkType)

When an invite is sent out to a signer, the invite URL can be directed either to the SWF application where the signer can see all their errands, but signers can also be directed directly to the document preview. This means the signer will circumvent SWF, which could be useful for citizens that might only want to sign the document and not use the SWF UI.

To use enable this functionality for solicitors, the following could be added to your config.json

{
  "orderOption": {
    "enableInviteUrlTargetOption": true | false,
    "defaultInviteUrlTarget": "SWF | SIGN_SERVICE"
  }
}
  • enableInviteUrlTargetOptions - Whether or not solicitors should be able to set the inviteUrlTarget in the UI.
  • defaultInviteUrlTarget - Default setting on where to direct signers, will default to SWF. Could be one of the following:
    • SWF - Signers are directed towards the SWF UI where users can see all their errands
    • SIGN_SERVICE - Signer are directed towards the document preview

This setting is set on errand level, meaning solicitors can not use different inviteUrlTarget 's to different signers.

Completion nextTarget

When an errand inviteUrlTarget is set to SIGN_SERVICE, errand creators can also decide where to redirect the user after a successful signing. What domain to redirect to can only be set per errand and not only when the errand is created via the API. Services and users, using the API, can set the completionNextTarget to a specific domain or URL to where the user will be redirected after a successful sign attempt.

Since this functionality might introduce potential security issues where errand creators can set a malicious redirect URL, administrators can restrict what domains can be used to redirect to by using the same domain whitelisting for nextTargetUrl as in PAS, see PAS documentation.

The configuration of the completion next target can be done as follows:

"completionNextTarget": {
  "enabled": true,
  "allowedLogoutTargetPrefix": ... ,
  "allowedLogoutTarget": ... ,
  "allowedLogoutTargetSuffix": ...
}
  • completionNextTarget - The wrapper for the completion nextTarget configuration
  • enabled - Wether or not the functionality should be enabled or not
  • allowedLogoutTargetPrefix - Regex for nextTarget prefix. See PAS documentation for more information.
  • allowedLogoutTarget - Regex for nextTarget. See PAS documentation for more information.
  • allowedLogoutTargetSuffix - Regex for nextTarget suffix. See PAS documentation for more information.

Landing page configuration

If administrators instead wants to configure the landing page instead of redirecting to another page, administrators can configure multiple landing page configurations that errand creators can use, using the completionNextTarget functionality.

To use this, the first step is to add landing page configurations to the completionNextTarget configuration.

"completionNextTarget": {
  "enabled": true,
  "configurations": {
    "landing_page_id_1": {
      "success": {
        "message": "landing_page_message"
      },
      "disableLogoutButton": true
    },
    "landing_page_id_2": {
      "success": {
      	"message": "other_landing_page_message",
      },
      "disableLogoutButton": false
    }
  }
}
  • completionNextTarget - The wrapper for the completion nextTarget configuration
  • enabled - Wether or not the functionality should be enabled or not
  • configurations - the configurations wrapper of the landing page configuration part. This is a JSON object, meaning all landing page keys needs to be unique.
    • success - A success message wrapper
      • message - The message localization key. For more information, see below
    • disableLogoutButton - Whether or not to disable the logout button. Defaults to false.

The above configuration enables two landing page configurations - landing_page_id_1 and landing_page_id_2. These are the ID's that is needed when creating an errand. Second, we must set up the localization keys associated with the IDs to decide what texts should be shown. The localization keys are found in the resources/lang/<language>/noapp.json and will be structured as follows:

"message_finalized_<landing-page-success-message>": "The errand is now signed."

Lastly, errand creators can utilize the landing page configuration by setting the property completionNextTarget to landingPageId=<the-desired-landing-page-id> to greet users with the configured landing page.

Example

Let's say an administrator sets up this configuration:

"completionNextTarget": {
  "enabled": true,
  "allowedLogoutTarget": ".*",
  "configurations": {
    "landing_page_id_1": {
      "success": {
        "message": "landing_page_message_1"
      },
      "disableLogoutButton": true
    },
    "landing_page_id_2": {
      "success": {
      	"message": "landing_page_message_2",
      },
      "disableLogoutButton": false
    }
  }
}

And then a noapp.json like this:

"message_finalized_landing_page_message_1": "ID 1 is configured"
"message_finalized_landing_page_message_2": "ID 2 is configured this time around"

Service A creates an errand with these to attributes set:

"inviteUrlTarget": "SWF"
"completionNextTarget": "https://google.com"

Result: Signers will be redirected to SWF after a successful signing. The completionNextTarget attribute will be ignored since the inviteUrlTarget is set to SWF.

Service B creates another errand with these attributes:

"inviteUrlTarget": "SIGN_SERVICE"
"completionNextTarget": "https://google.com"

Result: Signers will be redirected to https://google.com after a successful signing (the allowedLogoutTarget is set to ".*" which means all domains will be accepted in a redirect.)

Now, the administrator changes the configuration to:

"completionNextTarget": {
  "enabled": true,
  "allowedLogoutTargetPrefix", "^https?:\/\/[-a-zA-Z0-9\.-_]{1,256}\.site1\.se.*",
  "configurations": {
    "landing_page_id_1": {
      "success": {
        "message": "landing_page_message_1"
      },
      "disableLogoutButton": true
    },
    "landing_page_id_2": {
      "success": {
      	"message": "landing_page_message_2",
      },
      "disableLogoutButton": false
    }
  }
}

Service C creates an errand with these attributes:

"inviteUrlTarget": "SIGN_SERVICE"
"completionNextTarget": "https://google.com"

Result: Since the new configuration only accepts the domain site1.se, the URL https://google.com is refused. The signer will se the default no app-view after a successful signing

Service D creates an errand with these attributes:

"inviteUrlTarget": "SIGN_SERVICE"
"completionNextTarget": "landingPageId=landing_page_id_1"

Result: Signers will see the configured text for landing_page_id_1, which is "ID 1 is configured" after a successful sign attempt.

Service E creates an errand with these attributes:

"inviteUrlTarget": "SIGN_SERVICE"
"completionNextTarget": "landingPageId=landing_page_id_2"

Result: The users will see the configured text for landing_page_id_1, which is "ID 2 is configured this time around" after a successful sign attempt.

Service F creates an errand with these attributes:

"inviteUrlTarget": "SIGN_SERVICE"
"completionNextTarget": "landingPageId=landing_page_id_3"

Result: Since no configuration is found for landing_page_id_3, the user will see the default no app-view after a successful signing.

To update these settings, the application needs to be restarted.