How does access to change and prefilter visibility effect filtering?

Yes, it will if its value is calculated by code or set by default.

This allows using a prefilter for strict access separation to rows — a prefilter is created that is locked for the user, in which the value related to them is calculated.

For example, if we want to show only their rows to a manager, and all rows to others:

// 10 — role "manager"

=: if(condition: $#nr = 10; then: $#nu; else: "")

• $#nr — list of user roles, checking if it contains "manager".

• $#nu — id of the current user.

Yes, if the prefilter field is enabled in the web or API and hidden from the user, it will still be applied.

This allows for creating complex prefilters. For example, we want the user to be selected in the prefilter field, but the filtering to occur based on the company to which the user belongs:

// Code in the fl_teh_prefilter field

= : if(condition: #fl_user = ""; then: $#lc; else: $calc)

calc: selectList(table: 'table_users'; field: 'id'; where: 'company' = $company)
    company: select(table: 'table_users'; field: 'company'; where: 'id' = #fl_user)

In this case, we do not bind the fl_user prefilter to the row part, but bind the hidden fl_teh_prefilter.

For greater security, disable its editing as well.

Yes, the key factor here is the binding and edit access when adding.

If it is necessary to lock the field from finger errors, it can be locked through formatting:

f1=: setFormat(condition: #id = ""; block: true)

In this case, the field will be locked, but the auto-completion of the value will work.

No. In this case, the prefilter is disabled.