Рекомендації для розробників K2
Див.; додатково
Коміт має пояснювати, що саме змінено.;</syntaxhighlight>
Поля у K2Grid
Стандартні команди:
Чи можна робити зміни напряму в базі?
Тестові домени deb1-deb3
</syntaxhighlight>
formoptions:
version = "2.0.4.43"
[[Категорія:Рекомендації для розробників K2]]
Приклад:
{| class="wikitable" style="width:100%; background:#e8f5e9;"
|- | істотно. Коміт має бути зрозумілим іншому розробнику через місяць або рік.; `setup.py` — за параметри компоненти, включно з версією.; |}
getmaster: true
- K2 ERP
- K2 Cloud ERP
- Розробка веб-інтерфейсів K2
- Розгортання системи K2 Cloud ERP Python для розробників
- База даних K2 ERP
- Архітектура K2 ERP
- Компоненти K2 ERP
- K2Grid
- Магазин доповнень K2
- Сертифікація K2
- Python
- Git
- PostgreSQL
- API
addcaption: "+"
/папка_компоненти/res/menu/назва_меню.yml git status Перед початком роботи потрібно налаштувати користувача: </syntaxhighlight> </syntaxhighlight>
Рекомендації для документів
Якщо PyCharm використовує неправильний Python Interpreter, залежності можуть не відповідати проєкту.; * швидкість відкриття;
- зрозумілі назви полів;
- логічний порядок колонок;
- зручне сортування;
- фільтри;
- пошук;
- підсумки;
- ширину колонок;
- вирівнювання чисел;
- поведінку кнопок;
- обов’язкові поля;
- зрозумілі помилки;
- права доступу;
- роботу з великими обсягами даних.;
Middle-розробник має вміти будувати повноцінні модулі: * `name` — ідентифікатор меню; * `caption` — заголовок; * `addcaption` — додатковий текст або бейдж; * `addcaption_style` — стиль бейджа; * `iconclass` — клас іконки; * `url` — адреса переходу; * `command` — команда або зарезервований функціональні можливості.; Це фундамент більшості ERP-модулів.; Це має змогу бути backend-розробник, frontend-розробник, full-stack-розробник, Python-розробник, PHP-розробник, TypeScript/JavaScript-розробник, спеціаліст із PostgreSQL, інтегратор, розробник звітів, автор доповнень або технічний партнерська сторона.; Компонент у K2 має бути не хаотичним набором файлів, а структурованою частиною системи.; # скопіювати проєкт із віддаленого сервера; # перейти в каталог проєкту; # виконати `first_run.sh` або `first_run.bat`; # змінити `domain_protocol` з `https` на `http` для локального запуску; # запустити додаток через `run.sh` або `run.bat`; # відкрити проєкт у PyCharm; # налаштувати Python Interpreter на локальний `venv`; # встановити й налаштувати Git; # підключити потрібні компоненти; # перевірити роботу локального середовища.; Прийнято зберігати меню в каталозі:
істотно. Перед ручним підключенням компоненти потрібно розуміти, яка гілка застосовується, які файли вже є собою локально й чи не буде конфлікту з поточною версією.; * структуру бази даних;
payment_status show_for: "-1, 1" == Master-detail ==
'''Третій принцип — контроль даних.''' Будь-яка зміна в базі має бути зрозумілою, контрольованою й безпечною.;</span> Тут помилка в полі, праві доступу, SQL-запиті, імпорті або оновленні має змогу вплинути на реальні бізнес-процеси клієнта.; Після відкриття проєкту потрібно налаштувати інтерпретатор саме на локальне віртуальне середовище поточного проєкту.; Назва коміту не повинна бути випадковою.; Небажано.; Форма має допомагати користувачу створити або змінити запис без помилок.; Перед передачею — осмислений commit.;</span>
|}
<syntaxhighlight lang="yaml">
Для Windows:
Погані приклади:
Приклад календаря:
<syntaxhighlight lang="text">
Перед передачею компоненти потрібно перевірити:
|-
| `field`
| фактичне поле з SQL select
|-
| `alias`
| явне посилання на поле з урахуванням alias таблиці
|-
| `caption`
| назва колонки або підпис поля
|-
| `width`
| ширина колонки в гріді
|-
| `width_form`
| ширина поля у формі
|-
| `align`
| вирівнювання
|-
| `readonly`
| заборона редагування
|-
| `hidden`
| приховування колонки
|-
| `type_field`
| тип редактора
|-
| `def_value`
| значення за замовчуванням
|-
| `search`
| участь у пошуку
|-
| `sql`
| SQL для довідникового поля
|-
| `show_for`
| обмеження видимості за користувачами
|}
== Версії компонентів ==
|-
| '''істотно.''' <span style="color:#ef6c00;">Кожне поле, зазначене у `fields`, має бути в `select`, якщо воно застосовують, коли потрібно для відображення або логіки.;</span>
|}
Типові атрибути:
{| class="wikitable" style="width:100%; background:#fff3e0;"
* пошуку товарів;
* пошуку постачальників;
* підказок у довідниках;
* збереження документа;
* розрахунку сум;
* актуалізація табличної частини;
* перевірки даних;
* формування підсумків.;</span>
|}
'''Другий принцип — повторне використання.''' Якщо в K2 уже є собою грид, форма, довідник, фільтр, механізм імпорту, експорту або доступів, потрібно використовувати стандартну логіку, а не писати власну копію.; Це контрольований бізнес-процес обміну між K2 і зовнішньою системою.;</span> У результаті код має змогу запускатися не в з цієї причини середовищі, де встановлені потрібні залежності.; |}
git commit -m "характеристика зміни"
[[Категорія:Python]]
== Атестаційні задача для розробників ==
* `select` — SQL-джерело;
* `table` — логічна назва сутності;
* `typeid` — тип опису;
* `caption` — заголовок грида;
* `sortname` — поле сортування;
* `sortorder` — порядок сортування;
* `height` — висоту;
* `fields` — характеристика полів;
* `detile` — зв’язок із детальною таблицею;
* `getmaster` — режим деталі;
* `masterid` — поле зв’язку з майстром;
* `where` — фільтр для деталі.; |-
| '''Помилка.''' <span style="color:#b71c1c;">Оновити код компоненти, але не змінити версію й не додати запис у `history.txt` — це погана практика.;</span>
|}
{| class="wikitable" style="width:100%; background:#fff3e0;"
== SEO-призначення сторінки ==
* журнал документів;
* форму документа;
* табличну частину;
* статуси;
* проведення;
* друковану форму;
* звіт;
* інтеграцію з довідниками;
* права доступу;
* тестування;
* документацію;
* актуалізація компоненти.;=== Що таке auto_update? ===
|-
| '''Правильне тестування.''' <span style="color:#2e7d32;">Тестуйте не кнопку, а сценарій: користувач системи створив документ, додав рядки, зберіг, провів, надрукував і побачив результат у звіті.;</span> Готовність підтверджується тільки після перевірки на тестових середовищах.;<syntaxhighlight lang="text">
[[Категорія:Доступи K2 ERP]]
Публікація:
cond:
== Рекомендації щодо назв ==
|-
| '''Висновок.''' <span style="color:#ef6c00;">Більшість проблем у ERP-розробці виникає не через складний код, а через відсутність дисципліни: прав, тестів, версій, документації та розуміння процесу.; `auto_update` сприяє синхронізувати компоненти, клонувати актуальні версії, перевіряти статус і працювати зі списком компонентів більш організовано.; {| class="wikitable" style="width:100%; background:#e8f5e9;"
<syntaxhighlight lang="bash">
[[Категорія:Архітектура K2 ERP]]
У K2 багато інтерфейсів спираються на довідники: товари, контрагенти, працівники, склади, проєкти, статуси, види документів, валюти, статті бюджету.; Якщо потрібно підключити одну компоненту вручну, розробник переходить у каталог компоненти, ініціалізує Git, додає remote і отримує код із репозиторію.; Ці функції не можна робити без прав і перевірок.; ./run.bat </syntaxhighlight> Назви мають бути зрозумілими.; У файл `component-list.txt` додається список компонентів:
Приклад: Пов’язані сторінкиГірше: Четверта помилка — писати власний грид, коли є собою стандартний K2Grid.; |} python git_cmd.py clone |
| істотно. ERP-розробка відрізняється від звичайної веб-розробки.; │ ├── business_processes/ |
| істотно. Для довідників у K2Grid SQL має повертати зрозумілі `k` та `v`.; |
Приклад шляху для Windows:
ej2.min.js
!; Такий підхід надає можливість створювати гриди, поля, сортування, фільтри, кнопки, довідники, master-detail-зв’язки та інші елементи інтерфейсу без хаотичного ручного кодування.; Атрибут
cd components/k2site
builder/config
Для інтеграції потрібно описати:
</syntaxhighlight>
python k2update_push.py
Кожен компонент або компонент має мати документацію.; |}select id as k, name as v
Рекомендації для розробників K2 описують, як створювати модулі, компоненти, гриди, форми, документи, довідники, звіти, інтеграції й актуалізація так, щоб вони були підтримуваними, безпечними, документованими й сумісними з екосистемою K2.;
Junior-розробнику варто починати не зі складних інтеграцій, а з типових ERP-задач:
Тестування в K2 має перевіряти не тільки запуск сторінки, а повний бізнес-сценарій.; |- | Критично. Не можна вважати компонент готовим після push або завантаження на сервер оновлень.; cat ~/.ssh/id_rsa.pub |- | Архітектурний акцент. Master-detail — це базовий шаблон ERP: документ і рядки, замовлення і позиції, заявка і деталі.; * `deb1`;
- `deb2`;
- `deb3`.; |}
python git_cmd.py push
Документ у K2 — це не без ускладнень форма з полями.;</syntaxhighlight>
order_total
Розробник K2 має уважно ставитися до бази даних.; Якщо з назви неясно, що змінилося, супровід стає складнішою.; {| class="wikitable" style="width:100%; background:#fff3e0;"
cd auto_update Перед роботою з кодом розробник має підготувати локальне середовище.; реліз вказується у `setup.py`.; Розробник готовий до роботи з K2, якщо він: Потрібно правильно описати `select`, `fields`, DropDown-поля, master-detail-зв’язки, кнопки `condition`, права доступу, ширини колонок, пошук і сортування.; models.py {{SEO== Основні принципи розробки K2 ==
== Імпорт та експорт ==
| Типова помилка. Розробник відкрив проєкт у PyCharm, але не підключив правильний `venv`.;== Рекомендації для senior-розробника K2 ==
</syntaxhighlight> контроль змін, історію, можливість повернення до попередньої версії, командну роботу й підготовку компонентів до актуалізація реалізується засобами Git у K2 потрібен не формально.; |
Приклад:
Для модуля потрібно перевірити:
- номер;
- дату;
- автора;
- статус;
- контрагента;
- табличну частину;
- підсумки;
- друковану форму;
- зв’язок зі складом або фінансами;
- проведення;
- анулювання;
- історію;
- права доступу;
- формування звітів.; Серверна дія додатково має перевіряти права.;</syntaxhighlight>
У деталі:
Приклад:
</syntaxhighlight>
command:
fix
</syntaxhighlight>
істотно.
Перед `k2update_push.py` потрібно перевірити список компонентів, ignore-файли, токен, версію, history.txt і готовність до тестування.; Приклад шляху для Linux:Для кнопки через `condition`:
{| class="wikitable" style="width:100%; background:#e8f5e9;"
editoptions:
<syntaxhighlight lang="yaml">
.git
git remote -v
<syntaxhighlight lang="bash">
{| class="wikitable" style="width:100%; background:#fff3e0;"
version = "2.0.4.43"
|-
| '''Порада.''' <span style="color:#2e7d32;">Форма має підказувати правильне введення, а не чекати, поки користувач системи помилиться.;</span> Якщо цього не зробити, поле вибору має змогу працювати некоректно.; Добра назва зменшує потребу в зайвих коментарях.;== Тестування ==
|-
| '''істотно.''' <span style="color:#ef6c00;">Грид із десятьма тестовими рядками має змогу працювати добре, але з п’ятдесятьма тисячами записів — повільно.; Його копіюють у корінь проєкту на рівні з `app.py`, після чого в `settings.py` додають потрібні компоненти.; warehouseid
width: 30
Для документа потрібно продумати:
git fetch origin
Що таке рекомендації для розробників K2?
- змінювати бойову базу без процедури;
- пушити код без перевірки;
- робити актуалізація без версії;
- забувати `history.txt`;
- комітити токени й паролі;
- писати SQL без урахування продуктивності;
- створювати дублікати довідників;
- обходити стандартні права доступу;
- робити інтерфейс без валідації;
- залишати debug-режим у prod;
- публікувати компонент без тесту;
- копіювати стару логіку 1С/BAS без переосмислення;
- створювати компонент без документації.; version_type = "testing"
git checkout -b main У коді, YML, SQL і документації бажано уникати випадкових скорочень.; exp: (false) __pycache__
Як зрозуміти, що розробник готовий до K2
├── requirements.txt
== Сервер оновлень ==
Типові параметри меню:
{| class="wikitable" style="width:100%; background:#e3f2fd;"
|-
| '''Порада.''' <span style="color:#2e7d32;">Назва має пояснювати зміст.; Сьома помилка — комітити зміни без опису.; .gitignore
== Чек-лист перед передачею компоненти ==
|-
| '''Головна ідея.''' <span style="color:#2e7d32;">Розробник K2 має створювати не одноразову доробку, а підтримуваний елемент ERP-платформи.; |-
| '''Перевага.''' <span style="color:#2e7d32;">Добре структурована компонента легше тестується, оновлюється, документується й передається іншому розробнику.; cd /K2CloudERP
== Рекомендації для junior-розробника K2 ==
detile: document_rows
components/k2update
<syntaxhighlight lang="text">
[[Категорія:Безпека K2 ERP]]
Для DropDown-полів SQL часто має повертати ключ і значення:
<syntaxhighlight lang="yaml">
update
<syntaxhighlight lang="text">
[[Категорія:PHP]]
..\K2CloudERP\venv\Scripts\python.exe
{{DISPLAYTITLE:Рекомендації для розробників K2}}
Потрібно підготувати:
field: supplierid
├── example_module/
Тестові домени потрібні, щоб перевірити нову версію компоненти до використання в ширшому середовищі.; Після змін — `git status`.; AJAX має змогу використовуватися для:
class="wikitable" style="width:100%; background:#e8f5e9;"Компонентна технічна архітектура
Приклад одиниці виміру:
Типи полів
Чек-лист якості коду
new
Базовий порядок:
База даних і models.py
print:
Документація
supplierid:
│ ├── models.py
UX для розробника K2
Приклад:
Оновлено SQL для довідника постачальників У каталозі `builder/config/ignore` створюються файли з переліком того, що не потрібно завантажувати.;- які таблиці створюються;
- які поля використовуються;
- які зв’язки є собою між таблицями;
- які поля є собою обов’язковими;
- які індекси бажані;
- які інформаційні дані довідникові;
- які інформаційні дані операційні;
- як оновлюється структура;
- як компонент поводиться після міграції або актуалізація.; |}
Локальне середовище розробника
Інтеграції
order by name
[[Категорія:Розробка K2 ERP]]
{| class="wikitable" style="width:100%; background:#fff3e0;"
{| class="wikitable" style="width:100%; background:#ffebee;"
відповідає за структури даних компоненти.; Він має мати життєвий цикл.; Після актуалізація потрібно перевірити функціональність.; як ілюстрація, документ і таблична частина, замовлення і позиції, задача і рядки, накладна і товари.;</span>
|}
caption: Д
aaa
tmp2
* характеристика рішення для бізнесу;
* призначення;
* скриншоти;
* інструкцію встановлення;
* документацію користувача;
* документацію адміністратора;
* характеристика структури БД;
* права доступу;
* вимоги до версій;
* залежності;
* історію змін;
* політику підтримки;
* контакт автора;
* тестовий сценарій.;</span>
|}
Розробник має враховувати права доступу на кількох рівнях:
Восьма помилка — не оновлювати `setup.py` і `history.txt`.;
| істотно. компонент без документації — це технічний борг.; type_field: DropDown |
| UX-принцип. Добрий ERP-інтерфейс економить час користувача щодня, а не без ускладнень добре виглядає на демо.; |
<syntaxhighlight lang="bash">
* `date`;
* `datetime`;
* `checkbox`;
* `DropDown`;
* `condition`;
* текстові поля;
* числові поля;
* службові поля;
* приховані ID;
* кнопки-дії.; `views.py` — за логіку представлень.; |}
│ └── user_manual/
'''Розробник K2''' — це спеціаліст, який створює або підтримує роботу функціональність у межах ERP-платформи.; |}
Розробник K2 функціонує не без ускладнень з кодом.;</span>
|}
<syntaxhighlight lang="python">
П’ята помилка — забувати права доступу.; Прямі зміни в бойовій базі без процедури, backup, тестування й документації є собою ризиком для ERP.; Код має бути зрозумілим, компонент — документованим, інтерфейс — зручним, база даних — чистою, а актуалізація — перевіреним.;</syntaxhighlight>
K2Grid має змогу описувати таблиці через YML-файли.;
K2Grid і YML
Друга помилка — робити форму без розуміння статусів документа.;
Шостий принцип — документація. Якщо компонент не описаний, його важко підтримувати, передавати й продавати через екосистему K2.; Але приховати кнопку в інтерфейсі недостатньо.; python git_cmd.py pull Якщо компонент або компонент планується публікувати в магазині доповнень K2, вимоги мають бути вищими.;
Додано поле ПДВ у форму заявки на оплату
test
Продуктивність
ssh-keygen -t rsa -b 4096 -C "ваша_електронна_пошта@example.com"
Добра форма має:
Четвертий принцип — Git-дисципліна. Зміни мають фіксуватися, комітитися, пушитися, перевірятися й описуватися.; │ ├── hooks.py| ERP-принцип. Документ має не без ускладнень зберігатися, а змінювати стан системи: складський облік, фінансовий блок, звіти, статуси або аналітику.;== Меню компонентів == | |
| Практичний сенс. Атестаційне задача має перевіряти не знання синтаксису, а здатність створити реальний ERP-модуль.; Не можна: | |
Ризик. Експорт має змогу винести з ERP критичні інформаційні дані, а імпорт має змогу зіпсувати довідники або залишки.; `doc/schema` — за документацію структури бази даних.;== Коротко ==
from suppliersПісля зміни версії потрібно додати характеристика змін у `history.txt`.;== Підключення компоненти вручну == select supplierid as k, name as v * проєктувати модулі;
* визначати структуру БД;
* обирати правильні компоненти;
* контролювати продуктивність;
* проєктувати інтеграції;
* створювати reusable-рішення;
* перевіряти код інших;
* формувати стандарти;
* думати про актуалізація;
* зменшувати технічний борг;
* навчати молодших розробників.;</span> Якщо дія важлива, права мають перевірятися і на backend-рівні.; * створення простого довідника;
* конфігурація грида;
* створення форми;
* додавання фільтрів;
* робота з DropDown;
* створення кнопки `condition`;
* простий master-detail;
* валідація полів;
* невеликий звіт;
* робота з Git;
* актуалізація `history.txt`.; Він функціонує з ERP-платформою, у якій будь-яка зміна має змогу вплинути на документи, фінансовий блок, складський облік, доступи, користувачів, інтеграції, аналітику, актуалізація та інформаційні дані клієнта.; Якщо компонента створює нові таблиці, поля або зв’язки, це має бути описано в ORM-структурах і документації.; Без цього важко підтримувати актуалізація й розуміти історію змін.; `forms.py` — за форми.; `hooks.py` — за розширення поведінки.; x1
|-
| '''Технічний принцип.''' <span style="color:#1565c0;">Будь-яка зміна структури даних має бути зрозумілою, документованою й сумісною з оновленнями.; Senior-розробник відповідає не лише за код, а й за архітектуру.; У майстрі вказується детальна таблиця:
|-
| '''істотно.''' <span style="color:#ef6c00;">AJAX не скасовує серверну перевірку.;</span>
|}
- name: "k2test_phpgrid"
field: ' '
Для DropDown потрібно вказувати SQL, який повертає `k` і `v`.;== Що означає бути розробником K2 ==
|-
| '''істотно.''' <span style="color:#ef6c00;">Те, що функціонує на тестових десяти записах, має змогу не працювати на реальних ста тисячах документів.; Додано перевірку прав на експорт у K2Grid
У прикладі модуля надходження товарів документ має журнал, форму, табличну частину, розрахунок сум, проведення, зарахування товару на складський облік, друк товарної накладної та звіт руху товарів.; Перевіряйте продуктивність на реалістичних даних.; {| class="wikitable" style="width:100%; background:#e3f2fd;" Для списку компонент має змогу використовуватися скрипт `auto_update`.; YML-опис таблиці зазвичай містить: У K2Grid можуть використовуватися різні типи полів: bash run.sh
{| class="wikitable" style="width:100%; background:#e3f2fd;"
<syntaxhighlight lang="yaml">
== Поширені запитання ==
Схема роботи:
розробка програмного забезпечення для магазину доповнень K2 | |
| центральний висновок. Якісна розробка програмного забезпечення K2 — це дисципліна: компонентність, Git, база даних, права, UX, тестування, документація й відповідальність за бізнес-дані клієнта.; |
iconclass: "bi bi-grid-3x3"
Перша помилка — починати з коду, не зрозумівши бізнес-процес.; Після перевірки — push.;== Рекомендації для гридів ==
| Порада. Службові кнопки краще робити вузькими — 30–40 px, а пошук для них вимикати через `search: false`.; |
sql: |Для Python-розробки в K2 комфортно використовувати PyCharm.; {| class="wikitable" style="width:100%; background:#fff3e0;"
Перевага K2Grid. YML-опис надає можливість стандартизувати таблиці, зменшити дублювання коду й швидше створювати бізнес-інтерфейси.; * розуміє компонентну архітектуру;
</syntaxhighlight> Рекомендації для middle-розробника K2У файл `token.txt` додається токен доступу до сервера оновлень.; Потрібно: version_type = "stable" |
class="wikitable" style="width:100%; background:#e8f5e9;"
git add .; ERP — це документи, довідники, залишки, платежі, договори, фінансовий блок, складський облік, клієнти, задачі, маршрути погодження, доступи, звіти, інтеграції й відповідальність за інформаційні дані.; Для завантаження компонентів у систему актуалізація використовуються конфігурація в каталозі:
Зв’язок master-detail застосовується, коли є собою центральний запис і пов’язані рядки.; |
|---|
Після завантаження нової версії компоненти потрібно оновити її на тестових доменах:
ssh-add ~/.ssh/id_rsa
Окремо варто відзначити компонентів, веб-інтерфейсів, інтеграцій, гридів, форм, довідників, документів, звітів і бізнес-логіки в K2 ERP і K2 Cloud ERP виступає ключовою рисою розробників K2.; Меню до класів має змогу формуватися за допомогою масиву або автономно через YML-файл.;
У `fields` описуються колонки та поля форми.;</syntaxhighlight>
- коректно встановлюється;
- не ламає наявний функціональні можливості;
- сумісна з поточним середовищем;
- не створює помилок у залежних модулях;
- функціонує відповідно до опису в `history.txt`.; |}
|- | Критично. Не можна робити зміни “на живій базі”, без Git, без тестування, без опису версії та без розуміння бізнес-наслідків.;=== Навіщо тестувати на deb1-deb3? ===
│ └── templates/ Сторінка Рекомендації для розробників K2 має допомагати розробникам, партнерам і технічним командам знаходити правила створення якісних модулів для K2 ERP та K2 Cloud ERP: компоненти, Git, auto_update, K2Grid, YML, гриди, форми, база даних, права доступу, тестування, актуалізація, документація та безпека.; Він.; інтеграційні функціональні можливості — це не без ускладнень “передали інформаційні дані”.; Розробник має думати про:- джерело даних;
- отримувача;
- формат;
- правила авторизації;
- частоту обміну;
- журнал помилок;
- повторні спроби;
- відповідального;
- права доступу;
- сценарій відключення;
- вплив на базу даних.; ../K2CloudERP/venv/bin/python3.12
| Ознака якісного коду. Інший розробник має змогу відкрити компоненту, зрозуміти її структуру, запустити, протестувати й продовжити роботу без дзвінка автору.; Якщо назва поля, таблиці або змінної незрозуміла без автора, це майбутня проблема.; Дев’ята помилка — не тестувати компонент на `deb1`–`deb3`.; |
components/k2adm
python git_cmd.py commit
PyCharm і Python Interpreter
masterid: documentid git config --global user.email "ваша_електронна_пошта@example.com" git pull
[[Категорія:API]]
Кожна компонента, яка публікується або оновлюється, має мати версію.; Розробник K2 має думати про безпеку на кожному етапі.; Приклад `show_for`:
|-
| '''Технічний акцент.''' <span style="color:#1565c0;">інтеграційні функціональні можливості має бути підтримуваною: з логами, помилками, відповідальним і зрозумілою схемою даних.; Документація має описувати:
│ ├── schema/
└── setup.py
[[Категорія:Магазин доповнень K2]]
<syntaxhighlight lang="bash">
bash first_run.sh
where: " where (documentid='{masterid}') and (documentid<>'') "
supplierid
Код має бути:
<syntaxhighlight lang="bat">
|-
| '''Технічний акцент.''' <span style="color:#1565c0;">`name` у меню важливий не тільки для навігації, а й для майбутнього контролю доступів.; Імпорт і експорт мають бути контрольованими функціями.;== Рекомендації для форм ==
|-
| '''істотно для marketplace.''' <span style="color:#ef6c00;">Доповнення для магазину K2 має бути продуктом, а не архівом файлів.;</span>
|}
{| class="wikitable" style="width:100%; background:#ffebee;"
caption: Постачальник
* код закомічено;
* виконано `git status`;
* виконано `git pull`;
* конфлікти відсутні;
* версію оновлено в `setup.py`;
* характеристика змін додано в `history.txt`;
* компоненту додано в `component-list.txt`;
* ignore-файл налаштовано;
* токен не потрапив у репозиторій;
* компоненту завантажено через `k2update_push.py`;
* актуалізація перевірено на тестових доменах;
* гриди відкриваються;
* форми зберігаються;
* права працюють;
* імпорт і експорт перевірені;
* документація оновлена;
* помилки в логах перевірені.; Він має:
{| class="wikitable" style="width:100%; background:#e8f5e9;"
Розробник K2 має працювати через Git, дотримуватися компонентної архітектури, описувати структуру даних, перевіряти права доступу, тестувати зміни на окремих середовищах, оновлювати версії, вести `history.txt` і думати про реальний бізнес-процес, а не лише про код.; order by name
'''Рекомендації для розробників K2''' — це правила й практики створення модулів, компонентів, гридів, форм, документів, інтеграцій і оновлень у K2 ERP та K2 Cloud ERP.; │ ├── forms.py
|-
| '''Технічний акцент.''' <span style="color:#1565c0;">Розробник K2 функціонує на перетині коду, бази даних, бізнес-логіки, інтерфейсу, прав доступу та процесів підприємства.; Приклад:
dtt
|-
| '''Правильний підхід.''' <span style="color:#2e7d32;">Кожна розробка програмного забезпечення в K2 має відповідати трьом питанням: що вона робить, як її підтримувати, і що станеться після актуалізація.; Для K2 Cloud ERP Python типовий сценарій передбачає копіювання робочого проєкту, перший запуск, конфігурація віртуального середовища, запуск додатку, відкриття проєкту в PyCharm і підключення Git.; Файл:
== Робота з auto_update ==
2.0.4.43 - додано перевірку прав на експорт у журналі документів
== Git-дисципліна ==
ERP-інтерфейс має бути не без ускладнень красивим.; |}
== Що не можна робити розробнику K2 ==
summa2
{| class="wikitable" style="width:100%; background:#fff3e0;"
* хто має право імпорту;
* хто має право експорту;
* які поля можна вивантажувати;
* чи є собою персональні або фінансові інформаційні дані;
* чи потрібно журналювати дію;
* що робити з помилками імпорту;
* як уникати дублікатів;
* як повідомляти користувача про результат;
* чи потрібен шаблон імпорту.; document_date
ERP функціонує з великими обсягами даних.; eval "$(ssh-agent -s)"
url2: '/?adm=document&mode=admin&id={documentid}&op=print'
`models.py` відповідає за структури даних.;
</syntaxhighlight> Десята помилка — не писати документацію.; |}
- не робити зайвих запитів;
- не тягнути всі інформаційні дані без фільтрів;
- використовувати пагінацію;
- оптимізувати SQL;
- додавати індекси там, де потрібно;
- не перевантажувати dashboard;
- не робити важкий експорт без обмежень;
- перевіряти роботу на великих таблицях;
- уникати зайвих JOIN без потреби;
- логувати повільні або проблемні операції.; це набір практичних правил для створення забезпечується через Рекомендації; додатково реалізовано підтримки й розвитку модулів.; Воно має бути робочим dev-контуром, де можна безпечно розробляти, перевіряти й готувати зміни.; Перший принцип — компонентність. Якщо функціональність можна зробити як компонент, її не варто ховати в одноразовій доробці.;
| Критично. Не можна покладатися лише на приховування кнопки в UI.; Не можна: |
| Ознака готовності. Розробник K2 має мислити не “як зробити кнопку”, а “який бізнес-процес ця кнопка змінює”.; |
Вона покриває запити: “рекомендації для розробників K2”, “K2 ERP для розробників”, “розробка програмного забезпечення модулів K2”, “K2 Cloud ERP Python”, “K2Grid YML”, “компоненти K2 ERP”, “Git K2 ERP”, “auto_update K2”, “k2update_push.py”, “розробка програмного забезпечення ERP модулів”, “K2 ERP backend”, “K2 ERP frontend”, “українська ERP розробка програмного забезпечення”.;
components/k2site
123
- не дублювати записи;
- мати код або унікальний ідентифікатор;
- підтримувати пошук;
- підтримувати вибір у формах;
- мати зрозумілий текст відображення;
- не створювати “тимчасові” довідники без потреби;
- пов’язувати довідники зі спільною базою K2 ERP.; {| class="wikitable" style="width:100%; background:#e3f2fd;"
- зберігати паролі у відкритому вигляді;
- комітити токени;
- відкривати зайві права;
- залишати debug-інформацію в бойовому середовищі;
- дозволяти прямий доступ до даних без перевірки;
- давати всім право експорту;
- використовувати спільні логіни;
- виконувати SQL без контролю;
- тестувати небезпечні операції на prod;
- ігнорувати помилки авторизації.; Це призводить до помилок запуску, некоректної роботи модулів або різної поведінки в IDE та консолі.; з цієї причини розробка програмного забезпечення в K2 має бути не хаотичною, а керованою: через компоненти, Git, документацію, тестування, права доступу, версіонування й зрозумілу архітектуру.;
{| class="wikitable" style="width:100%; background:#e3f2fd;" == Типові помилки розробників K2 == git remote add origin http://git.corp2.eu/k2erp/python/k2/base/site/k2site.git # користувач системи вибирає рядок у майстрі; # K2Grid читає ID майстра; # значення підставляється в `{masterid}`; # детальна таблиця показує тільки пов’язані рядки.; Таке задача перевіряє: |- | '''Критично.''' <span style="color:#b71c1c;">Безпека в ERP — це не додаткова опція.; {| class="wikitable" style="width:100%; background:#e8f5e9;" У документації компоненти потрібно описувати: == SQL і довідники ==
git status
caption2:
<syntaxhighlight lang="yaml">
url: "?adm=k2test_phpgrid"
Чому потрібно оновлювати setup.py і history.txt?
python git_cmd.py status
class="wikitable" style="width:100%; background:#e8f5e9;" }git push
розробка програмного забезпечення в K2 має спиратися на кілька базових принципів.; Навіть якщо інтерфейс перевірив інформаційні дані на frontend, backend має повторно перевірити права, валідацію й бізнес-правила.; Він має бути зручним для щоденної роботи.; з цієї причини розробник має враховувати продуктивність ще під час проєктування.; як ілюстрація, компонент обліку надходження товарів на складський облік з управлінням партіями.;== Безпека розробки ==
Чому Git обов’язковий для розробки K2?
| Senior-рівень. Сильний розробник K2 не без ускладнень закриває задачу, а робить так, щоб наступні задачі закривалися швидше й безпечніше.; |
Що найважливіше для розробника K2Grid?
Права доступу в інтерфейсі
- ID-поля приховувати, але залишати доступними для логіки;
- дати показувати в зрозумілому форматі;
- числові колонки вирівнювати праворуч;
- службові кнопки робити вузькими;
- пошук для службових колонок вимикати;
- DropDown-поля будувати через `k` і `v`;
- не перевантажувати грид зайвими колонками;
- використовувати фільтри для великих реєстрів;
- перевіряти грид на реальних обсягах даних;
- описувати master-detail-зв’язки явно.; Для гридів бажано дотримуватися таких правил:
git init
}git config --global user.name "Ваше Ім'я"
caption: "PHPGrid Demo"
AJAX і збереження без перезавантаження
Git потрібен для контролю змін, командної роботи, історії версій, комітів, оновлень компонентів і безпечної підтримки ERP-коду.;
<syntaxhighlight lang="text">
- меню;
- грид;
- поле;
- кнопка;
- форма;
- серверна дія;
- API;
- база даних.; dataInit: "js:function(el){ $(el).datepicker({ dateFormat:'dd.mm.yy' }); }"