bitrix24-on-premise

name

bitrix24-on-premise

description

Administer, audit, troubleshoot, develop, integrate, migrate, update, and safely release self-hosted Bitrix24 (boxed/on-premise) and Bitrix Framework projects, including D7 and legacy PHP APIs, modules, components, ORM, agents/cron, caching, business processes, REST/REST 3.0, webhooks, OAuth, CRM permissions, sources, forms, robots, contact centers, Open Lines, online chat, site widgets, authenticated admin UI, BitrixVM, security, performance, backups, PHP/database upgrades, and closed-network deployments. Use when a task mentions Bitrix24 in a box, self-hosted Bitrix24, коробочный Битрикс24, 1C-Bitrix, Bitrix Framework, /bitrix, /local, BitrixVM, D7, BX.*, CModule, or Bitrix24 REST. This independent skill is built exclusively from publicly available official 1C-Bitrix/Bitrix24 documentation and official open GitHub repositories; it contains original workflows and links, not proprietary product code or private documentation.

Bitrix24 On-Premise

Use the target installation, its module versions, and verified live behavior as the technical source of truth. Use the bundled references as a concise navigation and decision layer over public official documentation.

Establish the evidence gate

1. Resolve the actual portal or repository root. Preserve unrelated changes.

2. Classify the request as advice, read-only diagnosis, implementation, migration/update, deployment, or production verification.

3. Classify the available access before inspecting anything:

   • source-backed box — portal files and repository are available;
   • remote administered box — only an authenticated UI and/or REST is available;
   • external integration — a separate website or service sends data to the portal.

4. For a source-backed box, run the read-only inspector:

   python3 scripts/inspect_bitrix24.py /path/to/portal
   

   Do not run it against an unrelated website or integration repository. For a remote administered box, collect the same facts from system check, module pages, safe REST discovery, and portal settings when available.

5. Record the main module version, relevant module versions, PHP, database, server topology, BitrixVM/BitrixEnv status, agent/cron mode, license/update state, backup state, and network restrictions when they affect the task.

6. Inspect git status, deployment metadata, the exact class/method/event, and available tests before changing files.

7. Recheck the current public official page for volatile requirements. Never assume that the newest online method exists in an older box.

Do not turn a read-only audit into a modification. Do not update, migrate, deploy, clear caches globally, submit CRM data, or expose a portal publicly without the corresponding user authorization.

Route the task

• Read official-sources.md for the canonical public documentation map, source hierarchy, licensing boundary, and search strategy.
• Read architecture-and-development.md for D7 versus legacy API, local/, modules, components, ORM, events, agents, caching, business processes, and implementation conventions.
• Read administration-and-operations.md for installation, updates, backups, PHP/database work, BitrixVM, cron, performance, clusters, and closed networks.
• Read rest-and-integrations.md for REST and REST 3.0, scopes, user permissions, webhooks, OAuth, events, batch, local apps, custom methods, network access, and 1C integrations.
• Read crm-admin-and-site-integrations.md for authenticated Codex/browser administration, effective CRM permissions, website lead forms, incoming webhooks, contact-center routing, Open Lines, online-chat widgets, behavioral UAT, cleanup, and operational work logs.
• Read security-and-release.md for secrets, personal data, threat boundaries, deployment gates, rollbacks, and acceptance evidence.

Search references before loading broad sections:

rg -n "crm\.item|EventManager|agents|PHP|PostgreSQL|closed network" references/

Operate authenticated portals safely

Before reading authenticated business data or changing a remote portal, show the detected portal, account, role, and intended scope and obtain the user's authorization. Inventory existing resources before creating or reusing a webhook, source, robot, CRM form, Open Line, channel, or widget. Reuse only when its owner, site, data contract, permissions, and lifecycle match.

Name every new administrative resource for its site and purpose. Capture its stable ID, pre-change settings, and rollback target. After each save, reload and reread the stored configuration; a successful click is not evidence that the portal persisted the intended state.

For CRM roles, calculate effective access across personal, department, group, inherited, and stage-specific rules. Do not infer a user's capability from one role or from the label of one permission. Verify the target behavior under the target user's effective permissions when authorized, especially stage changes on records owned by another employee.

Choose the correct extension layer

Prefer, in order:

1. product configuration, permissions, automation, or a business process when no code is required;
2. a documented event, REST integration, local app, webhook, or stable public extension point;
3. project code in local/modules, local/components, local/templates, or local/php_interface;
4. a narrowly isolated legacy extension only when the installed version lacks a suitable D7 or supported extension point.

Do not edit bitrix/modules, standard components, or other product core for a normal customization. If a core patch is unavoidable, isolate the diff, document the missing extension point, pin the affected product version, and provide an update/rebase and rollback procedure.

For new server-side code, start with D7 and namespaces. Use legacy APIs when the installed module or required capability has no equivalent. Confirm class, method, event, parameter, return type, and version in the installed source or the exact official reference page.

Enforce version-aware behavior

• Treat the main module and each feature module as independently versioned.
• Check module availability before calling Loader::includeModule() or a REST method.
• Treat deprecation markers as migration signals, not proof that the old API has already disappeared.
• Distinguish REST from REST 3.0 paths, request shapes, responses, and method coverage.
• Confirm database support against the product edition and current official requirements before proposing MySQL/PostgreSQL work.
• Treat current PHP, browser, BitrixVM, and licensing requirements as volatile. Verify them on the day of the change.

Protect data and production

• Never print or commit .settings.php, dbconn.php, webhook URLs, OAuth tokens, cookies, license keys, SMTP credentials, private keys, database dumps, customer records, or authenticated browser state.
• Keep secrets server-side and outside web root where the installation allows.
• Apply both application scope and acting-user permissions to REST reasoning.
• Validate authentication, authorization, CSRF/session intent, input types, output encoding, file handling, event authenticity, retry behavior, and idempotency.
• Back up files and database before platform, PHP, database, module, or Marketplace updates. Prove that restore is possible.
• Test on a representative non-production environment when an update or data migration can change availability or stored data.
• Prefer targeted cache invalidation. Never hide a defect behind a blind global cache purge.

Validate proportionally

For code changes, run the narrowest complete matrix available:

1. PHP syntax, static analysis, and existing automated tests.
2. The inspector again, with --strict for a release gate.
3. Module installation/update/uninstall paths when a custom module changes.
4. Authorized, unauthorized, invalid-input, duplicate-event, retry, and rollback cases for integrations.
5. Agent/cron, cache-disabled/cache-enabled, and concurrent execution behavior where relevant.
6. Desktop/mobile UI checks for components and portal pages.
7. Backup/restore, maintenance window, health checks, logs, queues, and live smoke tests for infrastructure work.
8. A clean diff proving that core, secrets, generated caches, uploads, and unrelated files were not changed accidentally.

For UI-managed integrations, also validate a newly isolated browser/session, the exact saved IDs and settings, one labeled synthetic end-to-end case, and cleanup of only the created test records. State what a single case did not prove, such as a full round-robin queue or absence handling.

Report detected versions, evidence sources, chosen extension point, changed files/settings, checks executed, deployment state, compatibility assumptions, and remaining risks. Distinguish local, GitHub, staging, and public production as separate gates.