Changes in version 2.32.4

In this version we have made many small and large improvements. especially to universal design and the rules for deletion. Version 2.32.4 is required to be able to upgrade to Flow version 1.5.2 .

Changes and bug fixes worth noting

Universal Design – We've made improvements to support the following requirements:

1.4.10 Reflow - Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions. Here we saw that our login wizard did not work optimally by 400 %. We have now corrected that. (SBF-2202, SBF-2205)

1.4.11 Non-text Contrast – Non-textual content must have a contrast ratio of at least 3:1 against the adjacent color(s). Here we have added a stronger frame around the rich text field to meet the requirement. (SBF-2201)

2.1.1 Keyboard - All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. In Interact, it works as follows: User can open dialogue, enter information and then leave it inactive for 20 minutes. After 20 minutes of inactivity, however, the browser session will expire, and any unsaved content will be lost. 5 minutes before the browser session expires, a warning will appear in the dialogue informing you of how many minutes remain. If the user presses OK and performs a simple action in the dialogue (for example, press the space bar), the browser session will be extended by another 20 minutes. Here we have made some improvements to make the solution more stable/consistent. (SBF-2198)

2.4.6 Headings and Labels - Headings and labels describe topic or purpose. Here we have made improvements in the code so that the Heading element in the dialogue will be stored as a heading at level 3. Title of dialogue is level 1, and step name is level 2. (SBF-2200)

3.1.1 Language of page – The default human language of each Web page can be programmatically determined. Here we have made some improvements when the user changes the language in the login wizard. (SBF-2199)

4.1.1 Parsing - In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. Here we have corrected a couple of small things. For example, step names was entered as H1 and H2 in code. We have fixed it so it only enters as H2. (SBF-2203, SBF-2200)

4.1.2 Name, Role, Value – For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. All components have a name and role determined in the code. Here we have made improvements in the code on navigation buttons. (SBF-2212)

Save user-uploaded attachments in submitted dialogues for - Many customers have a need to set a long lifetime on submitted dialogues so that the submitter can use the last submitted dialogue as a template for the next submission. A dialogue with data does not take up much space in the database, but user-uploaded attachments in submitted dialogues can fill up the database and make performance slow. Therefore, we have now made it possible to have a lower lifespan on user-uploaded attachments in submitted dialogues than what is set on submitted dialogues. The value is set in Settings – General – Maintenance. Lifetime of user-uploaded attachments in submitted dialogues will be set to 60 days by default. This is also the maximum value. You can lower the number of days, but the lifetime of user-uploaded attachments in submitted dialogues cannot be higher than submitted dialogues. You can also set the lifetime for user-uploaded attachments in submitted dialogues per dialogue, and here you can set a higher value than 60 days if this is necessary. The lifetime is set in Properties under the Maintenance tab. (SBF-2191)

Delete job - The CleanUp log shows how many lines are deleted as a result of the deletion rules set in Interact. We experienced that the CleanUp log stopped if there was too much data. We have therefore changed how often the deletion job runs, and how much is deleted on each run. The delete job previously ran once a day and then had a lot to delete. We have now changed so that the deletion job runs every time InteractMaintenanceEngine runs (every 5 minute), but that no more than 100 lines are deleted per deletion rule on each run. (SBF-2209)

LDAP Webservice (Azure AD) – In the latest version of the LDAP Webservice, you can now search for First Name, Middle Name and Surname (values must be in the DisplayName field in Azure AD). Previously, you could only search by username. The improvement also applies to groups. LDAP Webservice is a separate product and can be upgraded independently of Interact. (SBF-2122)

NetAxept and dispatch to custom file - When you set up dispatch to a custom file, you can tick the box so that the PDF is also dispatched to the same place. This should also work when NetAxept is used in the dialogue. We discovered that the PDF was no longer submitted together with the custom file when NetAxept was set up on a dialogue. We have now corrected this. (SBF-2146)

Custom file - Some customers have reported that the custom file has not been delivered, while submission and other dialogue dispatches have gone well. We have made some changes so that if the creation of a custom file fails, it already fails when the user presses "Submit". The user can then find the started dialogue under "My forms" and try again. (SBF-2218)

Lab - For security reasons, we have limited access to lab dialogues. As a dialogue designer, when you press Preview in Interact, a new browser window opens with the URL of the dialogue. This URL now contains a unique key (GUID) which is required to access the dialogue. It is no longer possible to navigate to the dialogue overview in the lab front. It is also not possible to navigate to a dialogue in the lab environment without the correct key in the URL. The key is unique per dialogue, and is valid for 24 hours. (SBF-2176)

Other bug fixes and improvements in this version

Preview - to get a preview of the receipt when you fill in the dialogue, mandatory fields on the active step must be filled in. We have added a validation for this and you will now be taken to the appropriate field that needs to be filled in. Once that's done, you can press the "Preview" button again. A new tab will open with a preview of the receipt as a PDF. This can be printed if necessary. We've also added a button text and a screen reader text that explains that preview opens in new tab. (SBF-2148, SBF-2162)

Headings – We saw that headings did not show as a highlighted centered heading in the dialogue, but looked more like an informational element. We have now corrected this. (SBF-2200)

Language - We found that the function of changing the language in the dialogue had stopped working properly. We have now corrected this. (SBF-2192)

Dialogue name - We have made some changes to remove a problem concerning dialogue that cannot be opened if the dialogue name is too long. (SBF-2210)

Save and view (Lab) and View (External) – If URL was missing / at the end in Settings – General – Preview, then Save and view (Lab) and View (External) in the dialogue designer would not work. This has now been corrected. (SBF-2151)

Radio button - We experienced that if we resumed a saved dialogue with a radio button list, the dialogue picked up the last choice on the radio button list, even if we had not selected anything here in the first place. We have now corrected this. (SBF-2153)

WebSak - When you set up a dispatch to WebSak in the dialogue designer, you can add more parties. Previously, the display of these was capped at 20 parties. Although it was possible to add more, it was not possible to see all of them in the dialogue designer - dispatch. We have now corrected this. In the case of several parties, a scroll bar will now appear. (SBF-2161)

Submitted date in PDF – Previously, when you resumed a saved dialogue, you got the date when this dialogue was first started as the submitted date in PDF. This was also applicable when the dialogue was part of a flow. The time would then be set to when the node was created and the task assigned, and not when the dialogue was actually submitted. We have now corrected this and the submitted date in the PDF will show the time the dialogue was actually submitted. (SBF-2152)

Log in - Some customers experienced that the Log in button in the Dialogue overview did not work properly externally. This has now been corrected. (SBF-2180)

Only used in Flow -We have renamed the text under Properties to "Only used in Flow, hidden from the form list and cannot be used as a template". If you have ticked this box for the dialogue only to be used in Flow, you should also not be able to use previously submitted dialogues as a template, as the template will lack a connection to the flow. We have changed it so that the "Use as template" icon is hidden for submitted dialogues where "Only used in Flow" is selected. We have also updated the text under Properties to "Only for use in Flow, hidden from the form list and cannot be used as a template". (SBF-2196)

URL parameters - You can add a string to the end of a dialogue URL that affects the dialogue in various ways. We saw that this did not work if the dialogue had an Azure or MitID login. We have now corrected this. (SBF-2170).

Dialogue ID - In Settings under General - Dialogue ID, we have changed the Dialogue Id prefix and number of digits to be read-only. (SBF-2217)

Changes made to new dispatch modules (cloud customers only)

Internal Dispatch - Some customers experienced that internal dispatch did not work. This has now been corrected. (SBF-2181)

Dispatch Log - Overview - We've made some changes to the Overview tab in the dispatch log. By default, it will be Overview that is displayed when you enter the dispatch log. Here you will see Number of deliveries in the last 30 days, whereas previously it was Number of deliveries in the last 24 hours. We have also added Manually handled to the overview. You can click on the numbers to go directly to the relevant dispatches in the List tab. (IACT-693)

The dispatch log - With regard to data security, we have chosen to limit the information displayed in the dispatch log. Information about all data that has been submitted in dialogues can still be found in submitted dialogue under the "Search" tab. In the event of a failed dispatch, you will receive a descriptive error message as before. This will contain a Correlation Id that you can attach to a support case if necessary. We will gradually expand with selected data, which we see as useful for you. (IACT-603, IACT-602, IACT-615, IACT-616, IACT-617, IACT-622, IACT-615, IACT-674, IACT-662)

Dispatch log – In the dispatch log, you can copy every single step in a dispatch by pressing this button . Now you can also copy the entire process for a dispatch, by pressing the same button at the bottom. (IACT-737)

The dispatch log - We have added a warning icon on failed dispatches to draw extra attention to them.

The dispatch log - Sometimes an unexpected error occurs that prevents Interact from creating the dispatch job. Previously, the dispatch was stopped with status Active and no details was created. We have now corrected this. In the event of a similar unexpected error, the dispatch will be given the status Failed and you will find a description of the error in the details. (IACT-611)

Multiple dispatches – If you have several dispatches on a dialogue, and one of them is disabled or for some reason fails, this should not stop the other dispatches on the dialogue. We found that this did not work, but it has now been corrected. If one of the dispatches in a submission fails, the dispatch will immediately receive the status Failed , but this will not stop the other dispatches in the submission. The same applies if you have deactivated one of the dispatches in a dialogue. Previously, a deactivated dispatch in a dialogue would also result in the dispatch being given the status Active . We have corrected that so that such a submission will now be given the status Completed as long as none of the dispatches have failed. (IACT-528)

E-mail notification in the event of a failed transfer to Dispatch+ (Dispatch log) – an e-mail notification is now sent if the transmission of dispatch data to Dispatch+ fails. The failed dispatch will also appear in the Error log under Submitted dialogue.

If you receive an e-mail notification about a failed transfer to Dispatch+ (Dispatch log), you can try the following to correct the error: In the Error log, you can press Reset . A new attempt will then be made, and if the attempt is successful, the dispatch will appear in the Dispatch log. Note! Here, the submission is left as Active , without dispatch taking place. Activate Advanced mode and select Rerun to trigger the dispatch attempt.

The recipient of the notification is the e-mail address that has been set up in Settings – General – Message – Message for transfer error or for dialogues under Properties - Maintenance - Notify when transfer has failed.

NOTE! E-mail notification in the event of a Dispatch+ error does not apply to dispatches that have the status Failed in the Dispatch log, but ONLY dispatches that for one reason or another do not appear in the Dispatch log at all, and therefore is not dispatched. (SF-2195, SBF-2216)

FileService – Customers have experienced that many and large attachments in a dialogue can lead to challenges with the submission of dispatch data to Dispatch+. We have therefore made arrangements for a new way of transferring submitted dialogues with attachments to Dispatch+. Technically, this means that we use an intermediate service that splits up the submission, so that data is sent in smaller packets. The solution will be introduced for all types of Dispatch+. We will activate the solution with our customers gradually and in a controlled manner. (IACT-675, IACT-671, IACT-713, IACT-673 (P360), IACT-680 (Email), IACT-687 (File), IACT-679 (Elements), IACT-715 (FINT)) .

NOTE! There is still a general limit of 50MB per submission. If your company needs more than this, it can be ordered. Please contact your supplier.

File – Interact can now support multiple Azure Blob Storage containers, so each container can have different settings as needed. You can add more Azure Blob Storage containers under Settings on the Dispatch+ settings tab. Enter the name of the container and click on icon to add it. Click Save and Update .

In the dialogue, you set up delivery to File as usual in the Dispatch+ tab, but now you also have to select Container name in the Container name drop-down menu.

In addition, you can now choose whether the dispatch should include dialogue as PDF and user-uploaded attachments. Here you have to make an active choice. You will no longer receive a censored PDF included in the dispatch. (IACT-598)

Please note that the existing dialogue with File Dispatch is not automatically linked to a container name. This must be set up per dialogue. If a dialogue is submitted without the dialogue being linked to a container, the dispatch will fail. This can easily be rectified by updating the existing dialogue with the correct container name. Then use the Run again function in the Dispatch log (IACT-550 and IACT-593)

Elements – We've made several changes and fixes to Elements' dispatch.

1. You can now choose New Case . If you choose this, a new Case ID will be created in Elements for each dialogue that is submitted. When New Case is selected, you will find the Case ID in the Interact Dispatch Log at the very end of a successful dispatch, under the status "Dialogue dispatched to Elements". See pictures below.

2. We have replaced "Case no" with "Case and sequence". IMPORTANT! Note that the Case ID that was added to the existing dialogue under "Case no" is now gone as the field is gone. The case ID must therefore be re-entered on the existing dialogue under "Case and sequence".

   

   

3. The most recent NOARK requirements require that a description is stated in Classifications. We have therefore added Description under Classifications . This field is mapped to the relevant value in Acos2Element. (IACT-574, IACT-600, IACT-659)

   

   NB! If you have not selected New Case, this means that a search for existing case must be done. If something has been entered in Case and sequence (either archive case ID or year/sequence number), a lookup will be made against this upon dispatch. If, on the other hand, nothing has been entered in the Case and sequence field, it will check the classifications. If classifications are also missing, then the dispatch will fail.

4. The field "Unoff" (except public) will be added to the sender in the Elements dispatch when Skjermes (shielded) is switched on. We saw that this did not work in the new dispatch. This has now been fixed. (IACT-604)

   

5. We have made some corrections that affect, among other things, the display/non-display of Title2 on documents (IACT-668), the sorting of classifications (IACT-658) and that Folder Type (Type) is included in the dispatch (IACT-670).

P360 - In the old dispatch module, document is created with a person/organisation as an unregistered contact, if the dialogue does not contain an organization number or national identity number. Now this also works in the new dispatch module. (IACT-583)

Certain customers experienced that they had completed dispatches in the dispatch log, but these had not changed their status from Active to Completed. This has now been fixed. (IACT-645)