Document Verification Filters

91 Aufrufe Markdown

The rules that decide which clients are asked to verify themselves with documents before they can keep using their account.

Reaching the Screen

Open Clients, then Document Verification, then Filters: {admin}/users/document-verification/filters

The whole Document Verification menu appears only for staff holding the USERS_DOCUMENT_VERIFICATION privilege.

What Is on the Screen

An explanatory bar, a row of controls, and the list of filters. Everything else happens in the dialog that opens when you add or open a filter.

Information bar A reminder of what filters do: a client caught by one is required to complete verification and cannot use the account until it is done.

Controls Bulk action, the add button, links to the two sibling pages (Verification Fields and Document Verification Records), a status filter for the list, and the download button that saves the list as CSV, JSON or XML.

Filter list One row per filter, with its conditions listed in their own column beside the name.

Filter dialog Where a filter is actually built: status, name, conditions, and the fields to request.

Name Your own name for the filter, for staff only. Clicking it opens the filter for editing.

Filters The conditions this filter carries, one line each. Only the condition type is listed here, not the value behind it, so open the filter to see the thresholds.

Status Active or inactive. Only active filters are ever evaluated.

Row actions Edit and delete, in the menu at the end of the row.

The status control above the list narrows the rows to active or inactive filters, and the choice stays in the address, so a filtered list survives a page reload.

The Filter Dialog

The same dialog is used to add a filter and to open an existing one. It has four parts, top to bottom:

Status The switch that puts the filter into service. A new filter opens with it on.

Name How the filter is labelled in the list and on the client's record on the Document Verification Records page. Staff only: the client never sees it.

Filters The conditions. Each row is one condition: a type on the left, its value on the right, and a bin icon to drop it. The plus button under the rows adds another one, and the last remaining row cannot be removed.

Fields What the client will be asked for. Pick a field from the list underneath and add it; the chosen fields stack up above and can be dragged into the order the client will see. With no field defined anywhere yet, a warning takes the picker's place and links you to the Verification Fields page.

The save button starts closed and opens as soon as you touch anything in the dialog.

Condition Types

Eighteen types are available. The numeric ones also carry a comparison (Equal, Less, Greater), which the dialog preselects for you.

Condition	What it reads	What you enter
According to Account Type	The account type on the profile.	Individual or Company.
According to Age	Age from the date of birth. An account with no date of birth never matches.	An age and a comparison. The Between choice has no second value to work with and is evaluated as Greater.
By Country and City	The country (and optionally the state or city) on the client's address.	A country, and a state or city once the country is chosen.
According to Last Login Day	Days since the last sign-in. An account that has never signed in does not match.	A number of days. Matches at that number and above.
According to VPN/Proxy Usage	Whether the address the client is connecting from reads as a proxy or VPN.	Yes or No.
According to IP Subnet	The address the client is connecting from.	A pattern with * for the free parts, such as 192.168.1.*.
According to Reseller Status	Whether the account is a reseller.	Yes or No.
According to Affiliate Status	Whether the account has an affiliate record.	Yes or No.
According to Client Group	The client group on the account.	One group.
According to Total Spending	The sum of the client's paid invoices. Amounts are added up without converting currencies.	An amount and a comparison.
According to Order Count	How many orders the account has, of any status.	A count and a comparison.
According to Service Count	How many services the account has, of any status.	A count and a comparison.
Country Mismatch (IP ≠ Profile)	The country on the profile against the country of the last sign-in. If either one is unknown, the condition does not match.	Yes or No.
According to Account Age	Days since registration.	A number of days and a comparison.
According to Payment Method	Whether the client has at least one paid invoice settled with that method.	One payment method.
According to Email Provider	The domain of the client's e-mail address.	A domain, such as gmail.com.
According to Failed Payments	Unpaid invoices that are past their due date. There is no separate log of failed attempts, so overdue invoices stand in for payment trouble.	A count and a comparison.
According to Product Group	Whether the client owns a service in that group. Domains count as a group of their own.	One product group.

How a Filter Catches a Client

A filter's conditions are joined with or, not and: one matching condition is enough to catch the client. Several conditions in one filter therefore widen the net rather than narrowing it. There is no way to require two conditions to hold at the same time, neither inside one filter nor across two. Opening a second filter widens the net again; what it changes is that the second filter's own field list joins the request.

Two things keep a filter out of play entirely: an inactive status, and an empty field list. A filter that asks for nothing has nothing to enforce and is skipped.

When more than one filter catches the same client, their fields are merged into a single request list and duplicates are dropped, so a field two filters both ask for is presented once. Fields whose own status is inactive are left out of that list.

Fields

Name Required. Saving with it empty is refused. Staff-facing only: the name appears in this list and on the client's record on the Document Verification Records page, in the list row and in the review dialog. The client never sees the filter's name anywhere.

Status On by default for a new filter. Off keeps the filter and its conditions but takes it out of evaluation.

Select a field to add... The picker that adds one of the defined verification fields to this filter. At least one field must end up in the list; saving without one is refused. A field already in the list cannot be added twice.

Apply to Selected Shown only to staff who may edit filters. Delete is its only action, it works on the rows ticked in the list, and it always asks for your own password, even when a single row is ticked.

Tasks

Create a filter

Use the add button above the list.
Name the filter, then set its first condition.
Add the fields to be requested and drag them into the order the client should see.
Save. The filter joins the list, and with its status on it starts catching clients from the next account check.

Set the conditions

In the Filters section of the dialog, choose the type on the left; the fields on the right change with it.
Enter the value, and the comparison where the type offers one.
Use the plus button for a second condition, remembering that conditions are joined with or.
Save. The list row now shows every condition type in the Filters column next to the filter's name.

Choose what the client is asked for

Pick a field from the picker in the Fields section and add it.
Repeat for each field, then drag the rows by their handle to set the order.
Remove anything you do not need with the cross at the end of its row.
Save. The chosen fields are what the caught client sees on their verification page.

Take a filter out of service

Open the filter from its name in the list.
Switch Status off and save.
The row now reads Inactive. No new client is caught by it, and the clients it already caught are released from its request, unless another active filter asks for the same fields.

Delete filters

For one filter, use delete in its row menu.
For several, tick their rows and choose Delete under Apply to Selected. That route always asks for your own password, so use the row menu when a single filter is going.
Confirm. The rows leave the list, and the documents clients already submitted stay where they are, because those belong to the fields rather than to the filter.

Things to Watch

A caught client stays caught

The moment a client trips a filter, the match is written onto their account. Editing the conditions afterwards does not release them: while the filter stays active its rules are never weighed again. Switching the filter off or deleting it does drop its request. Test a new filter on a narrow condition before widening it.

An active filter locks accounts, not just flags them

A caught client cannot use their panel until every requested field carries a verified record. Turning a broad filter on therefore stops existing clients in their tracks, and the queue it creates is worked through on the Document Verification Records page.

An inactive field is silently skipped

The picker offers every defined field, inactive ones included, but it does not mark them there: the Inactive badge appears only once the field has been added to the list above. An inactive field sits in the filter without ever being asked, so a filter holding only inactive fields catches clients and requests nothing from them.

Required Privileges

The whole screen sits behind USERS_DOCUMENT_VERIFICATION: without it the menu entry is not drawn and the page refuses to open. The same privilege covers every action here (adding, editing, deleting and bulk deleting filters), so there is no read-only level for this screen. Downloading the list additionally requires TABLE_EXPORT; without it the download button is not drawn.

War das hilfreich?

Vielen Dank für Ihre Rückmeldung!

Brauchen Sie weitere Hilfe?

Unser Support-Team ist rund um die Uhr für Sie da, wenn Sie oben nicht fündig werden.

Kontakt aufnehmen Ticket eröffnen