Latest SOGo release is v5.12.9, could you please upgrade SOGo packages and try again?

Update after upgrading to SOGo 5.12.9:
Upgraded SOGo to 5.12.9.20260630-1 (latest nightly, released today) as suggested. Result is identical — ModulesConstraints still has no effect with MySQL/MariaDB backend.
Test setup:

User user@domain.tld with enablesogowebmail = 'n' (varchar(1)) in vmail.mailbox
sogo.users view correctly exposes c_webmail column (confirmed via SHOW CREATE VIEW)
ModulesConstraints added inside SQL SOGoUserSources block in sogo.conf:

ModulesConstraints = {
    Mail = { c_webmail = y; };
    Calendar = { c_calendar = y; };
    ActiveSync = { c_activesync = y; };
};
SOGo log after restart and fresh login (no cached session):
SOGoRootPage successful login from 'x.x.x.x' for user 'user@domain.tld' - expire = -1  grace = -1
POST /SOGo/connect HTTP/1.0" 200
Login succeeds despite c_webmail = n. No constraint evaluation visible in logs.
Additional finding: The three iRedAdmin-Pro toggles (enablesogowebmail, enablesogocalendar, enablesogoactivesync) appear to be silently ignored by SOGo regardless of version. The only flag that actually enforces access via the sogo.users view is enablesogo (master toggle), which blocks all SOGo access including EAS and CalDAV — too coarse for per-service control.
Current workaround: nginx-level redirect of /SOGo, /SOGo/ and /SOGo/connect to Roundcube (/mail). Global block only, no per-user granularity.
Is ModulesConstraints actually supported for SQL backends in any SOGo version? If not, should iRedAdmin-Pro hide or disable these per-service toggles to avoid misleading administrators?

SOGo log extract confirming successful login despite enablesogowebmail = 'n' in vmail.mailbox:

Jun 30 20:11:25 sogod [15240]: SOGoRootPage successful login from '172.16.x.x' for user 'user@domain.tld' - expire = -1  grace = -1
Jun 30 20:11:25 sogod [15240]: 172.16.x.x "POST /SOGo/connect HTTP/1.0" 200 84/94 0.044 - - 0 - 13
====

---

**[Bug Report] iRedAdmin-Pro SOGo per-user flags (enablesogowebmail, enablesogocalendar, enablesogoactivesync) have no effect on SOGo behavior**

**Description:**

iRedAdmin-Pro exposes three per-user toggles under SOGo Groupware:
- SOGo Webmail
- SOGo Calendar
- SOGo ActiveSync

These map to columns `enablesogowebmail`, `enablesogocalendar` and `enablesogoactivesync` in `vmail.mailbox`, which are exposed via the `sogo.users` view as `c_webmail`, `c_calendar` and `c_activesync` respectively.

Disabling any of these flags in iRedAdmin-Pro has no effect on SOGo behavior. Users with `enablesogowebmail = 'n'` can still log in to the SOGo webmail interface. Users with `enablesogoactivesync = 'n'` and `enablesogocalendar = 'n'` can still authenticate via EAS (HTTP 200) and CalDAV (HTTP 207 Multi-Status).

**Verification:**

Confirmed that the `sogo.users` view correctly exposes the columns:

```sql
SHOW CREATE VIEW sogo.users\G
-- Result includes:
-- enablesogowebmail AS c_webmail
-- enablesogocalendar AS c_calendar
-- enablesogoactivesync AS c_activesync
```

Confirmed column type in `vmail.mailbox`:
```sql
SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'vmail' AND TABLE_NAME = 'mailbox'
AND COLUMN_NAME = 'enablesogowebmail';
-- Result: varchar(1)
```

Added `ModulesConstraints` to `/etc/sogo/sogo.conf` inside the SQL `SOGoUserSources` block, using the syntax from the official iRedMail sample:

```
ModulesConstraints = {
    Mail = { c_webmail = y; };
    Calendar = { c_calendar = y; };
    ActiveSync = { c_activesync = y; };
};
```

After restarting SOGo, users with `enablesogowebmail = 'n'` can still log in successfully. SOGo log confirms:

```
SOGoRootPage successful login from '172.16.x.x' for user 'user@domain.tld' - expire = -1  grace = -1
POST /SOGo/connect HTTP/1.0" 200
```

**Root cause (suspected):**

This appears to be related to SOGo bug #5390 (ModulesConstraints and SQL column type VARCHAR(1)), which was reported as resolved but the behavior persists in SOGo 5.9.0 with MySQL/MariaDB backend. The `ModulesConstraints` directive does not appear to be enforced for SQL authentication sources in this version.

**Impact:**

The per-user SOGo service flags in iRedAdmin-Pro are effectively non-functional. Administrators who disable SOGo Webmail, Calendar or ActiveSync for specific users via iRedAdmin-Pro will see no actual restriction applied. This is a silent failure with no warning in the UI or logs.

**Workaround currently in use:**

Blocking SOGo web access at the nginx level by redirecting `/SOGo`, `/SOGo/` and `/SOGo/connect` to `/mail` (Roundcube). This is a global block and does not allow per-user granularity.

**Question:**

Is there a supported way to enforce per-user SOGo service restrictions (webmail, calendar, ActiveSync) with a MySQL/MariaDB SQL backend in iRedAdmin-Pro 5.8 / SOGo 5.9.0? If `ModulesConstraints` is not functional for SQL sources, should the iRedAdmin-Pro UI reflect this limitation?