25 March 2024 (v2.109)

ReachFive v2.109 introduces job report filtering, allowing you to filter job reports directly from the ReachFive Console. You can now also sync Naver consents to ReachFive. We also made some other improvements. As always, we fixed some issues for you.

Release highlight

Filter job reports

You can now filter job reports from the ReachFive Console. Filtering the reports helps you more easily find the job report you’re looking for. The job report filters offers several ways to filter as shown in the table below. This includes setting a timeframe and how the results are displayed.

For more, see Job reports.

2109 filter reports
Filter Description

Job ID

Filter by a specific job ID that has been run.

This filter is particularly useful when you need to look into a specific job. Perhaps, you obtained the ID through logs or need to investigate further.

Job definition ID

Filter by a job definition ID.

This filter is useful when you want to look at a particular job definition. Maybe, you want to see how often it’s been run, or why a specific job definition is succeeding or failing.

Job type

Filter by the type of job such as export or import.

The job type filter is good to filter out only the type of jobs you want to see.

Job status

Filter by the status of the job.

Statuses
  • SUCCESS

  • RUNNING

  • WAITING

  • WAITING_CANCELLATION

  • CANCELED

  • FAILURE



In order to receive the user consents from Naver into ReachFive, you need to ensure that during integration, ReachFive consents are assigned the opt-in type and that the consent’s key matches the same consent key in Naver.

You must also specify every consent used in your brand’s Naver app in the ReachFive Console. If the consent does not exist, the user is still able to authenticate. Consents are only collected the first time a user authenticates via Naver.

For more, see Naver.

social Naver console steps



Other improvements

  • Previously, the authenticator_selection object in the WebAuthn Identity API responses was empty. Now. the resident_key and user_verification fields are valued with preferred.

    ...
    "authenticator_selection": {
        "resident_key": "preferred", (1)
        "user_verification": "preferred" (1)
    
    },
    ...
    1 Indicates the Relying Party strongly prefers creating a client-side discoverable credential, but will accept a server-side credential.



Fixes

Item Fixed

In some cases when creating a user with the Management API, the created_at date on the associated user event was incorrect.

Consents logs on the ReachFive Console were temporarily display in chronological order by default instead of the expected reverse chronological order.

Activating the Multi-factor Authentication feature without SMS activated caused the email templates to be unintentionally unavailable.