Перейти до вмісту

Рекомендації для розробників K2

Матеріал з K2 ERP Wiki

Що не можна робити розробнику K2

{| class="wikitable" style="width:100%; background:#e3f2fd;"

Таке задача перевіряє:

<syntaxhighlight lang="text">
|-
| '''Головна ідея.''' <span style="color:#2e7d32;">Розробник K2 має створювати не одноразову доробку, а підтримуваний елемент ERP-платформи. Серверна дія так само має перевіряти права. ./run.bat

== Документація ==

=== Чому Git обов’язковий для розробки K2? ===

У майстрі вказується детальна таблиця:

{| class="wikitable" style="width:100%; background:#ffebee;"

Вона покриває запити: “рекомендації для розробників 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 розробка програмного забезпечення”. {| class="wikitable" style="width:100%; background:#fff3e0;"

Поширені запитання

|- | критично. Коміт має бути зрозумілим іншому розробнику через місяць або рік. Назва коміту не повинна бути випадковою. models.py Якщо потрібно підключити одну компоненту вручну, розробник переходить у каталог компоненти, ініціалізує Git, додає remote і отримує код із репозиторію.</syntaxhighlight> `models.py` відповідає за структури даних. where: " where (documentid='{masterid}') and (documentid<>) " |- | критично. Для довідників у K2Grid SQL має повертати зрозумілі `k` та `v`. ..\K2CloudERP\venv\Scripts\python.exe

git checkout -b main

  • джерело даних;
  • отримувача;
  • формат;
  • правила авторизації;
  • частоту обміну;
  • журнал помилок;
  • повторні спроби;
  • відповідального;
  • права доступу;
  • сценарій відключення;
  • вплив на базу даних. |-

| Правильне тестування. Тестуйте не кнопку, а сценарій: користувач системи створив документ, додав рядки, зберіг, провів, надрукував і побачив результат у звіті. Якщо дія важлива, права мають перевірятися і на backend-рівні. |}

YML-опис таблиці зазвичай містить:

</syntaxhighlight>

  • журнал документів;
  • форму документа;
  • табличну частину;
  • статуси;
  • проведення;
  • друковану форму;
  • звіт;
  • інтеграцію з довідниками;
  • права доступу;
  • тестування;
  • документацію;
  • оновлення версій компоненти.

|}

Назви мають бути зрозумілими. ../K2CloudERP/venv/bin/python3.12 

│ ├── views.py
Шоста помилка — не перевіряти SQL на реальних обсягах даних.

x1

Перед початком роботи потрібно налаштувати користувача:

Приклад шляху для Linux:

  • створення запису;
  • редагування;
  • видалення або заборону видалення;
  • пошук;
  • фільтри;
  • сортування;
  • довідники;
  • вибір через AJAX;
  • проведення документа;
  • зміну статусу;
  • друк;
  • звіти;
  • імпорт;
  • експорт;
  • права різних ролей;
  • помилки валідації;
  • роботу після оновлення версій;
  • роботу на реальних обсягах даних. git status

components/k2site Якщо компонент або компонент планується публікувати в магазині доповнень K2, вимоги мають бути вищими. так само middle-розробник має думати про продуктивність, безпеку, підтримку й сумісність. |}

Шостий принцип — документація. Якщо компонент не описаний, його важко підтримувати, передавати й продавати через екосистему K2. |}

type_field: DropDown </syntaxhighlight> width: 30 from suppliers show_for: "-1, 1" Перед передачею компоненти потрібно перевірити: select supplierid as k, name as v Отриманий публічний ключ потрібно додати у віддалений репозиторій. {| class="wikitable" style="width:100%; background:#e3f2fd;"

Навіщо тестувати на deb1-deb3?

components/k2update Розробник K2 має працювати через Git, дотримуватися компонентної архітектури, описувати структуру даних, перевіряти права доступу, тестувати зміни на окремих середовищах, оновлювати версії, вести `history.txt` і думати про реальний бізнес-процес, а не лише про код. Приклад календаря:
Архітектурний акцент. Master-detail — це базовий шаблон ERP: документ і рядки, замовлення і позиції, заявка і деталі.
git pull
  • створення простого довідника;
  • конфігурація грида;
  • створення форми;
  • додавання фільтрів;
  • робота з DropDown;
  • створення кнопки `condition`;
  • простий master-detail;
  • валідація полів;
  • невеликий звіт;
  • робота з Git;
  • оновлення версій `history.txt`. Перевіряйте продуктивність на реалістичних даних.

Публікація:

</syntaxhighlight>

  • зберігати паролі у відкритому вигляді;
  • комітити токени;
  • відкривати зайві права;
  • залишати debug-інформацію в бойовому середовищі;
  • дозволяти прямий доступ до даних без перевірки;
  • давати всім право експорту;
  • використовувати спільні логіни;
  • виконувати SQL без контролю;
  • тестувати небезпечні операції на prod;
  • ігнорувати помилки авторизації. Типові атрибути:

Технічний принцип. Будь-яка зміна структури даних має бути зрозумілою, документованою й сумісною з оновленнями. Після змін — `git status`.

Додано перевірку прав на експорт у K2Grid

Приклад шляху для Windows:

  • `deb1`;
  • `deb2`;
  • `deb3`.

|}

git remote -v

version = "2.0.4.43" 

# скопіювати проєкт із віддаленого сервера;
# перейти в каталог проєкту;
# виконати `first_run.sh` або `first_run.bat`;
# змінити `domain_protocol` з `https` на `http` для локального запуску;
# запустити додаток через `run.sh` або `run.bat`;
# відкрити проєкт у PyCharm;
# налаштувати Python Interpreter на локальний `venv`;
# встановити й налаштувати Git;
# підключити потрібні компоненти;
# перевірити роботу локального середовища. |}

 │ ├── models.py

Сьома помилка — комітити зміни без опису. formoptions:

== Пов’язані сторінки ==
|-
| '''Типова помилка.''' <span style="color:#b71c1c;">Розробник відкрив проєкт у PyCharm, але не підключив правильний `venv`.</span> Це частина кожної форми, кожного API, кожного SQL-запиту й кожної кнопки. Прийнято зберігати меню в каталозі:

* коректно встановлюється;
* не ламає наявний функції ERP;
* сумісна з поточним середовищем;
* не створює помилок у залежних модулях;
* функціонує відповідно до опису в `history.txt`. |-
| '''Правильна звичка.''' <span style="color:#2e7d32;">Перед змінами — `git pull`.

document_date

  • хто має право імпорту;
  • хто має право експорту;
  • які поля можна вивантажувати;
  • чи виступає як персональні або фінансові інформаційні дані;
  • чи потрібно журналювати дію;
  • що робити з помилками імпорту;
  • як уникати дублікатів;
  • як повідомляти користувача про результат;
  • чи потрібен шаблон імпорту.=== Чи можна робити зміни напряму в базі? ===

Чек-лист якості коду

UX для розробника K2

payment_status

.gitignore

Друга помилка — робити форму без розуміння статусів документа. |}

Не можна:

Master-detail

│ ├── business_processes/

Типові помилки розробників K2

tmp2

Кращі приклади: │ └── user_manual/ Краще:
components/
`setup.py` містить версію компоненти, а `history.txt` пояснює, що саме змінилося. Це призводить до помилок запуску, некоректної роботи модулів або різної поведінки в IDE та консолі.

Як зрозуміти, що розробник готовий до K2

</syntaxhighlight>

У файл `token.txt` додається токен доступу до сервера оновлень.

Для модуля потрібно перевірити: 

{| class="wikitable" style="width:100%; background:#ffebee;"

 type_field: condition

Розробник K2 функціонує не без зусиль з кодом.</span> Готовність підтверджується тільки після перевірки на тестових середовищах. Для testing/beta-версії:
[[Категорія:ORM]]
print:
== Рекомендації для форм ==
== Коротко ==
Для документа потрібно продумати:
[[Категорія:PostgreSQL]]
`auto_update` — це скрипт для роботи зі списком компонентів: клонування, перевірки статусу, комітів, pull і push. {| class="wikitable" style="width:100%; background:#e8f5e9;"

Кожен компонент або компонент має мати документацію.== Компонентна технічна архітектура ==
|-
| '''Практичний сенс.''' <span style="color:#1565c0;">Атестаційне задача має перевіряти не знання синтаксису, а здатність створити реальний ERP-модуль. |}

Потрібно:

== Чек-лист перед передачею компоненти ==

summa2

* зрозумілі підписи;
* обов’язкові поля;
* валідацію;
* підказки;
* автоматичне заповнення там, де це доречно;
* логічне групування полів;
* правильну ширину інпутів;
* одиниці виміру;
* календарі для дат;
* маски або перевірки для номерів;
* захист від помилкового збереження;
* поведінку відповідно до статусу документа. Він функціонує з ERP-платформою, у якій будь-яка зміна здатна вплинути на документи, фінансовий блок, складський облік, доступи, користувачів, інтеграції, аналітику, оновлення версій та інформаційні дані клієнта.<syntaxhighlight lang="yaml">
<syntaxhighlight lang="bash">
П’ята помилка — забувати права доступу.</span> Його мають розуміти, встановлювати, оновлювати й підтримувати інші люди.</span>
|}

== Рекомендації для senior-розробника K2 ==

ERP-інтерфейс має бути не без зусиль красивим.</span>
|}

Для DropDown-полів SQL часто має повертати ключ і значення:

* [[K2 ERP]]
* [[K2 Cloud ERP]]
* [[Розробка веб-інтерфейсів K2]]
* [[Розгортання системи K2 Cloud ERP Python для розробників]]
* [[База даних K2 ERP]]
* [[Архітектура K2 ERP]]
* [[Компоненти K2 ERP]]
* [[K2Grid]]
* [[Магазин доповнень K2]]
* [[Сертифікація K2]]
* [[Python]]
* [[Git]]
* [[PostgreSQL]]
* [[API]]

== Інтеграції ==
{| class="wikitable" style="width:100%; background:#e3f2fd;"
Приклад:
python git_cmd.py commit
[[Категорія:TypeScript]]
 ├── requirements.txt
== Сервер оновлень ==
 command:
Імпорт і експорт мають бути контрольованими функціями. Це здатна бути backend-розробник, frontend-розробник, full-stack-розробник, Python-розробник, PHP-розробник, TypeScript/JavaScript-розробник, спеціаліст із PostgreSQL, інтегратор, розробник звітів, автор доповнень або технічний інтегратор. sql: |

== База даних і models.py ==

[[Категорія:K2Grid]]

== Продуктивність ==
|-
| '''провідний висновок.''' <span style="color:#2e7d32;">Якісна розробка програмного забезпечення K2 — це дисципліна: компонентність, Git, база даних, права, UX, тестування, документація й відповідальність за бізнес-дані клієнта. Не можна:

Після оновлення версій потрібно перевірити функціональність. Його копіюють у корінь проєкту на рівні з `app.py`, після чого в `settings.py` додають потрібні компоненти. Тому розробка програмного забезпечення в K2 має бути не хаотичною, а керованою: через компоненти, Git, документацію, тестування, права доступу, версіонування й зрозумілу архітектуру. Для Windows:

* `select` — SQL-джерело;
* `table` — логічна назва сутності;
* `typeid` — тип опису;
* `caption` — заголовок грида;
* `sortname` — поле сортування;
* `sortorder` — порядок сортування;
* `height` — висоту;
* `fields` — SEO-опис полів;
* `detile` — зв’язок із детальною таблицею;
* `getmaster` — режим деталі;
* `masterid` — поле зв’язку з майстром;
* `where` — фільтр для деталі. Якщо компонента створює нові таблиці, поля або зв’язки, це має бути описано в ORM-структурах і документації.</span>
|}

Розробник має думати про:

Після зміни версії потрібно додати SEO-опис змін у `history.txt`.== Робота з auto_update ==
`auto_update` оптимізує синхронізувати компоненти, клонувати актуальні версії, перевіряти статус і працювати зі списком компонентів більш організовано. git fetch origin

* пошуку товарів;
* пошуку постачальників;
* підказок у довідниках;
* збереження документа;
* розрахунку сум;
* оновлення версій табличної частини;
* перевірки даних;
* формування підсумків.[[Категорія:Українська ERP]]

cd /K2CloudERP

Junior-розробнику варто починати не зі складних інтеграцій, а з типових ERP-задач:

Імпорт та експорт

from table_name

SEO-призначення сторінки

У K2 багато інтерфейсів спираються на довідники: товари, контрагенти, працівники, склади, проєкти, статуси, види документів, валюти, статті бюджету. Без цього важко підтримувати оновлення версій й розуміти історію змін.== PyCharm і Python Interpreter == Приклад:

Гірше:

class="wikitable" style="width:100%; background:#fff3e0;" </syntaxhighlight> 
cat ~/.ssh/id_rsa.pub

{| class="wikitable" style="width:100%; background:#e3f2fd;"

Дев’ята помилка — не тестувати компонент на `deb1`–`deb3`. git commit -m "SEO-опис зміни"

Документ у K2 — це не без зусиль форма з полями. Пізніше буде складно зрозуміти, що саме було змінено. Прямі зміни в бойовій базі без процедури, backup, тестування й документації виступає як ризиком для ERP. {| class="wikitable" style="width:100%; background:#ffebee;" </syntaxhighlight> У файл `component-list.txt` додається список компонентів:

Але приховати кнопку в інтерфейсі недостатньо.== Типи полів ==

Технічний акцент. інтеграційні функції ERP має бути підтримуваною: з логами, помилками, відповідальним і зрозумілою схемою даних. це набір практичних правил для створення забезпечується через Рекомендації; так само реалізовано підтримки й розвитку модулів. Сторінка Рекомендації для розробників K2 має допомагати розробникам, партнерам і технічним командам знаходити правила створення якісних модулів для K2 ERP та K2 Cloud ERP: компоненти, Git, auto_update, K2Grid, YML, гриди, форми, база даних, права доступу, тестування, оновлення версій, документація та безпека. Мета цього етапу — переконатися, що нова реліз системи:
Перевага. Добре структурована компонента легше тестується, оновлюється, документується й передається іншому розробнику. supplierid

warehouseid Виправлено фільтр за статусом у журналі документів

iconclass: "bi bi-grid-3x3"
  1. користувач системи вибирає рядок у майстрі;
  2. K2Grid читає ID майстра;
  3. значення підставляється в `{masterid}`;
  4. детальна таблиця показує тільки пов’язані рядки.

</syntaxhighlight>

Документація має описувати: 

├── doc/

Git у K2 потрібен не формально. AJAX здатна використовуватися для:

ERP-принцип. Документ має не без зусиль зберігатися, а змінювати стан системи: складський облік, фінансовий блок, звіти, статуси або аналітику. У результаті код здатна запускатися не в тому середовищі, де встановлені потрібні залежності. │ ├── hooks.py

python git_cmd.py clone

test

Розробник K2 має уважно ставитися до бази даних. 2.0.4.43 - додано перевірку прав на експорт у журналі документів

Ознака якісного коду. Інший розробник здатна відкрити компоненту, зрозуміти її структуру, запустити, протестувати й продовжити роботу без дзвінка автору. П’ятий принцип — тестування до публікації. Компонент не можна вважати готовим, якщо він не перевірений на тестовому середовищі. addcaption: "+"
критично для marketplace. Доповнення для магазину K2 має бути продуктом, а не архівом файлів. відповідає за структури даних компоненти. masterid: documentid

Для сучасних веб-модулів K2 критично підтримувати роботу без зайвого перезавантаження сторінки. ! Senior-розробник відповідає не лише за код, а й за архітектуру. Окремо варто відзначити компонентів, веб-інтерфейсів, інтеграцій, гридів, форм, довідників, документів, звітів і бізнес-логіки в K2 ERP і K2 Cloud ERP виступає ключовою рисою розробників K2. |-

Порада. Форма має підказувати правильне введення, а не чекати, поки користувач системи помилиться. `views.py` — за логіку представлень. Це означає, що поле або кнопка показується тільки користувачам із відповідними ID. У прикладі модуля надходження товарів документ має журнал, форму, табличну частину, розрахунок сум, проведення, зарахування товару на складський облік, друк товарної накладної та звіт руху товарів.
Для перевірки розробника корисні практичні задачі, які імітують реальні бізнес-сценарії. url2: '/?adm=document&mode=admin&id={documentid}&op=print'
|-
| '''критично.''' <span style="color:#ef6c00;">AJAX не скасовує серверну перевірку.</span>
|}

Рекомендації щодо назв

Форма має допомагати користувачу створити або змінити запис без помилок.

Рекомендації для розробників K2 — це правила й практики створення модулів, компонентів, гридів, форм, документів, інтеграцій і оновлень у K2 ERP та K2 Cloud ERP. builder/config

Senior-рівень. Сильний розробник K2 не без зусиль закриває задачу, а робить так, щоб наступні задачі закривалися швидше й безпечніше. order by name
Технічний акцент. auto_update потрібен для дисципліни роботи з компонентами, особливо коли проєкт складається не з одного модуля, а з багатьох пов’язаних частин. реліз системи вказується у `setup.py`. * розуміє компонентну архітектуру;
  • функціонує з Git без хаосу;
  • не боїться бази даних;
  • пише зрозумілі SQL-запити;
  • вміє робити гриди й форми;
  • думає про права доступу;
  • тестує сценарії;
  • документує зміни;
  • не переносить старі помилки з 1С/BAS;
  • розуміє, що ERP — це бізнес-процеси, а не лише код. |-
 критично. Те, що функціонує на тестових десяти записах, здатна не працювати на реальних ста тисячах документів.</syntaxhighlight>
Кожна компонента, яка публікується або оновлюється, має мати версію. newnew Приклад: Приклад: │ └── templates/ Компонент у K2 має бути не хаотичним набором файлів, а структурованою частиною системи. У `fields` описуються колонки та поля форми. * номер;
  • дату;
  • автора;
  • статус;
  • контрагента;
  • табличну частину;
  • підсумки;
  • друковану форму;
  • зв’язок зі складом або фінансами;
  • проведення;
  • анулювання;
  • історію;
  • права доступу;
  • формування звітів. |}
|-
| '''критично.''' <span style="color:#ef6c00;">ERP-розробка відрізняється від звичайної веб-розробки.[[Категорія:Ролі K2 ERP]]

Git потрібен для контролю змін, командної роботи, історії версій, комітів, оновлень компонентів і безпечної підтримки ERP-коду. '''Четвертий принцип — Git-дисципліна.''' Зміни мають фіксуватися, комітитися, пушитися, перевірятися й описуватися. |}

Якщо PyCharm використовує неправильний Python Interpreter, залежності можуть не відповідати проєкту. |}

[[Категорія:Компоненти K2 ERP]]

== Права доступу в інтерфейсі ==

cond:

Розробник готовий до роботи з K2, якщо він: 

caption2:
  • `name` — ідентифікатор меню;
  • `caption` — заголовок;
  • `addcaption` — додатковий текст або бейдж;
  • `addcaption_style` — стиль бейджа;
  • `iconclass` — клас іконки;
  • `url` — адреса переходу;
  • `command` — команда або зарезервований функції ERP.
url: "?adm=k2test_phpgrid"

cd auto_update </syntaxhighlight> git push 

== Рекомендації для middle-розробника K2 ==
/папка_компоненти/res/menu/назва_меню.yml
components/k2adm
Для DropDown потрібно вказувати SQL, який повертає `k` і `v`. Приклад:
== AJAX і збереження без перезавантаження ==
cd components/k2site
└── example_module/

 ├── example_module/
|-
| '''критично.''' <span style="color:#ef6c00;">Локальне середовище не повинно бути копією хаосу з бойового сервера.
Розробник K2 має думати про безпеку на кожному етапі. |}
field: supplierid 
У деталі:
git config --global user.name "Ваше Ім'я"
{| class="wikitable" style="width:100%; background:#fff3e0;"
order_total
Восьма помилка — не оновлювати `setup.py` і `history.txt`. git pull origin main
|-
| '''Заборона.''' <span style="color:#b71c1c;">Не виправляйте проблему “оперативно в базі”, якщо це має бути зміна компоненти, міграції, моделі або бізнес-логіки. Атрибут
|-
| '''Критично.''' <span style="color:#b71c1c;">Безпека в ERP — це не додаткова опція. |}

 caption: Постачальник
|-
| '''Критично.''' <span style="color:#b71c1c;">Не можна робити зміни “на живій базі”, без Git, без тестування, без опису версії та без розуміння бізнес-наслідків. {| class="wikitable" style="width:100%; background:#fff3e0;"
__TOC__

[[Категорія:База даних K2 ERP]]

{| class="wikitable" style="width:100%; background:#e3f2fd;"

[[Категорія:Корпоративна Wiki]]
|-
| '''Критично.''' <span style="color:#b71c1c;">Не можна покладатися лише на приховування кнопки в UI. |}

Четверта помилка — писати власний грид, коли виступає як стандартний K2Grid. Схема роботи:

* які таблиці створюються;
* які поля використовуються;
* які зв’язки виступає як між таблицями;
* які поля виступає як обов’язковими;
* які індекси бажані;
* які інформаційні дані довідникові;
* які інформаційні дані операційні;
* як оновлюється структура;
* як компонент поводиться після міграції або оновлення версій. Він забезпечує контроль змін, історію, можливість повернення до попередньої версії, командну роботу й підготовку компонентів до оновлення версій. Файл:
Коміт має пояснювати, що саме змінено. `setup.py` — за параметри компоненти, включно з версією. Якщо назва поля, таблиці або змінної незрозуміла без автора, це майбутня проблема. |}

version_type = "stable"

Він має:

Десята помилка — не писати документацію. Меню до класів здатна формуватися за допомогою масиву або автоматизовано через YML-файл. Після відкриття проєкту потрібно налаштувати інтерпретатор саме на локальне віртуальне середовище поточного проєкту. ! │ ├── forms.py

UX-принцип. Добрий ERP-інтерфейс економить час користувача щодня, а не без зусиль добре виглядає на демо. Такий підхід дає можливість створювати гриди, поля, сортування, фільтри, кнопки, довідники, master-detail-зв’язки та інші елементи інтерфейсу без хаотичного ручного кодування. Його складно підтримувати, сертифікувати, передавати партнеру або публікувати в магазині доповнень.
критично. компонент без документації — це технічний борг.</syntaxhighlight>

dtt 

[[Категорія:JavaScript]]

{| class="wikitable" style="width:100%; background:#ffebee;"
|-
| '''Правильний підхід.''' <span style="color:#2e7d32;">Кожна розробка програмного забезпечення в K2 має відповідати трьом питанням: що вона робить, як її підтримувати, і що станеться після оновлення версій. Приклад одиниці виміру:

[[Категорія:Рекомендації для розробників K2]]

* читабельним;
* логічно структурованим;
* без зайвого дублювання;
* без хардкоду там, де потрібні конфігурація;
* без паролів у репозиторії;
* із зрозумілими назвами;
* із перевірками помилок;
* із журналюванням критичних дій;
* із перевіркою прав;
* із валідацією вхідних даних;
* сумісним з оновленнями. Це фундамент більшості ERP-модулів.</span>
|}

{| class="wikitable" style="width:100%; background:#fff3e0;"

Базовий порядок:

{| class="wikitable" style="width:100%; background:#fff3e0;"

* призначення модуля;
* бізнес-сценарій;
* структуру бази даних;
* таблиці;
* поля;
* гриди;
* форми;
* меню;
* права доступу;
* конфігурація;
* інтеграції;
* друковані форми;
* звіти;
* порядок тестування;
* відомі обмеження;
* історію змін.</span> Ці функції не можна робити без прав і перевірок.</span> Навіть якщо інтерфейс перевірив інформаційні дані на frontend, backend має повторно перевірити права, валідацію й бізнес-правила. Типові параметри меню:

=== Що найважливіше для розробника K2Grid? ===
У K2Grid можуть використовуватися різні типи полів:
== Що означає бути розробником K2 ==

Перед роботою з кодом розробник має підготувати локальне середовище. `hooks.py` — за розширення поведінки.</span> Якщо цього не зробити, поле вибору здатна працювати некоректно.<syntaxhighlight lang="bash">

* швидкість відкриття;
* зрозумілі назви полів;
* логічний порядок колонок;
* зручне сортування;
* фільтри;
* пошук;
* підсумки;
* ширину колонок;
* вирівнювання чисел;
* поведінку кнопок;
* обов’язкові поля;
* зрозумілі помилки;
* права доступу;
* роботу з великими обсягами даних. select id as k, name as v

{| class="wikitable" style="width:100%; background:#e8f5e9;"
== Локальне середовище розробника ==
new
fix
Для гридів бажано дотримуватися таких правил:
Типова структура компоненти здатна містити:
python git_cmd.py push
У документації компоненти потрібно описувати:

version_type = "testing"
|-
| '''Технічний акцент.''' <span style="color:#1565c0;">`name` у меню важливий не тільки для навігації, а й для майбутнього контролю доступів. як приклад, документ і таблична частина, замовлення і позиції, задача і рядки, накладна і товари. ./first_run.bat

* структуру бази даних;
* довідники товарів і постачальників;
* журнал документів;
* форму документа;
* AJAX-збереження;
* табличну частину;
* автоматичні розрахунки;
* проведення документа;
* друковану форму;
* звіт руху товарів;
* якість коду;
* безпеку;
* UX. - name: "k2test_phpgrid"

=== Чому потрібно оновлювати setup.py і history.txt? ===
[[Категорія:Сертифікація K2]]
<syntaxhighlight lang="yaml">
|-
| `field`
| фактичне поле з SQL select
|-
| `alias`
| явне посилання на поле з урахуванням alias таблиці
|-
| `caption`
| назва колонки або підпис поля
|-
| `width`
| ширина колонки в гріді
|-
| `width_form`
| ширина поля у формі
|-
| `align`
| вирівнювання
|-
| `readonly`
| заборона редагування
|-
| `hidden`
| приховування колонки
|-
| `type_field`
| тип редактора
|-
| `def_value`
| значення за замовчуванням
|-
| `search`
| участь у пошуку
|-
| `sql`
| SQL для довідникового поля
|-
| `show_for`
| обмеження видимості за користувачами
|}

<syntaxhighlight lang="bash">
|-
| '''критично.''' <span style="color:#ef6c00;">Кожне поле, зазначене у `fields`, має бути в `select`, якщо воно застосовують, коли потрібно для відображення або логіки.</span>
|}

{{SEO
|title=Рекомендації для розробників K2 — компоненти, Git, Python, гриди, форми, база даних, UX та безпека ERP
|description=Рекомендації для розробників K2 — Wiki-стаття про правила розробки модулів, веб-інтерфейсів, компонентів, гридів, форм, довідників, документів, API, бази даних, Git, тестування, оновлень, безпеки та UX у K2 ERP і K2 Cloud ERP.
|keywords=рекомендації для розробників K2, K2 ERP для розробників, K2 Cloud ERP розробка, розробка модулів K2, компоненти K2 ERP, K2Grid, K2 ERP Python, Git K2 ERP, auto_update K2, k2update_push.py, models.py K2, forms.py K2, views.py K2, API K2 ERP, база даних K2 ERP, розробка ERP модулів, українська ERP
|alternativeTo=хаотична розробка ERP; локальні доробки без Git; ручні зміни в базі; форми без UX; модулі без документації; інтеграції без журналювання; оновлення без тестування; 1С-доробки; BAS-доробки
}}

розробка програмного забезпечення в K2 має спиратися на кілька базових принципів. Тут помилка в полі, праві доступу, SQL-запиті, імпорті або оновленні здатна вплинути на реальні бізнес-процеси клієнта.

git status

ej2.min.js

Після завантаження нової версії компоненти потрібно оновити її на тестових доменах:

</syntaxhighlight> 

Перша помилка — починати з коду, не зрозумівши бізнес-процес.</span>
|}

supplierid:

== Атестаційні задача для розробників ==

* меню;
* грид;
* поле;
* кнопка;
* форма;
* серверна дія;
* API;
* база даних.== Рекомендації для гридів ==

* змінювати бойову базу без процедури;
* пушити код без перевірки;
* робити оновлення версій без версії;
* забувати `history.txt`;
* комітити токени й паролі;
* писати SQL без урахування продуктивності;
* створювати дублікати довідників;
* обходити стандартні права доступу;
* робити інтерфейс без валідації;
* залишати debug-режим у prod;
* публікувати компонент без тесту;
* копіювати стару логіку 1С/BAS без переосмислення;
* створювати компонент без документації.<syntaxhighlight lang="bash">
 └── setup.py

 caption: Д

'''Третій принцип — контроль даних.''' Будь-яка зміна в базі має бути зрозумілою, контрольованою й безпечною. |}

git add .</span>
|}

<syntaxhighlight lang="yaml">

{| class="wikitable" style="width:100%; background:#ffebee;"

* ID-поля приховувати, але залишати доступними для логіки;
* дати показувати в зрозумілому форматі;
* числові колонки вирівнювати праворуч;
* службові кнопки робити вузькими;
* пошук для службових колонок вимикати;
* DropDown-поля будувати через `k` і `v`;
* не перевантажувати грид зайвими колонками;
* використовувати фільтри для великих реєстрів;
* перевіряти грид на реальних обсягах даних;
* описувати master-detail-зв’язки явно.[[Категорія:Доступи K2 ERP]]
інтеграційні функції ERP — це не без зусиль “передали інформаційні дані”. як приклад, компонент обліку надходження товарів на складський облік з управлінням партіями. Це контрольований бізнес-процес обміну між K2 і зовнішньою системою.</span>
|}

Оновлено SQL для довідника постачальників

<syntaxhighlight lang="bash">
  • не дублювати записи;
  • мати код або унікальний ідентифікатор;
  • підтримувати пошук;
  • підтримувати вибір у формах;
  • мати зрозумілий текст відображення;
  • не створювати “тимчасові” довідники без потреби;
  • пов’язувати довідники зі спільною базою K2 ERP.</syntaxhighlight>
}

git init

Перший принцип — компонентність. Якщо функціональність можна зробити як компонент, її не варто ховати в одноразовій доробці. Він має мати життєвий цикл. Тому розробник має враховувати продуктивність ще під час проєктування.

ssh-add ~/.ssh/id_rsa 

<syntaxhighlight lang="text">

* SEO-опис рішення для бізнесу;
* призначення;
* скриншоти;
* інструкцію встановлення;
* документацію користувача;
* документацію адміністратора;
* SEO-опис структури БД;
* права доступу;
* вимоги до версій;
* залежності;
* історію змін;
* політику підтримки;
* контакт автора;
* тестовий сценарій. |-
| '''критично.''' <span style="color:#ef6c00;">Перед `k2update_push.py` потрібно перевірити список компонентів, ignore-файли, токен, версію, history.txt і готовність до тестування. '''Розробник K2''' — це спеціаліст, який створює або підтримує функціональність у межах ERP-платформи.</span>
|}

ssh-keygen -t rsa -b 4096 -C "ваша_електронна_пошта@example.com"

Для кнопки через `condition`:

* код закомічено;
* виконано `git status`;
* виконано `git pull`;
* конфлікти відсутні;
* версію оновлено в `setup.py`;
* SEO-опис змін додано в `history.txt`;
* компоненту додано в `component-list.txt`;
* ignore-файл налаштовано;
* токен не потрапив у репозиторій;
* компоненту завантажено через `k2update_push.py`;
* оновлення версій перевірено на тестових доменах;
* гриди відкриваються;
* форми зберігаються;
* права працюють;
* імпорт і експорт перевірені;
* документація оновлена;
* помилки в логах перевірені. Для авторизації через SSH:

Зв’язок master-detail застосовується для, коли виступає як провідний запис і пов’язані рядки.</span>
|}

 field: ' '

 caption: "PHPGrid Demo"

== K2Grid і YML ==

 dataInit: "js:function(el){ $(el).datepicker({ dateFormat:'dd.mm.yy' }); }"
bash run.sh
editoptions:
python k2update_push.py

{| class="wikitable" style="width:100%; background:#ffebee;"

Приклад: Додано поле ПДВ у форму заявки на оплату

Стандартні команди:

bash first_run.sh

Підключення компоненти вручну

│ ├── objects/

</syntaxhighlight>

Помилка. Оновити код компоненти, але не змінити версію й не додати запис у `history.txt` — це погана практика.=== Що таке auto_update? ===

</syntaxhighlight>

критично. Перед ручним підключенням компоненти потрібно розуміти, яка гілка застосовується для, які файли вже виступає як локально й чи не буде конфлікту з поточною версією. Для K2 Cloud ERP Python типовий сценарій передбачає копіювання робочого проєкту, перший запуск, конфігурація віртуального середовища, запуск додатку, відкриття проєкту в PyCharm і підключення Git. Перед передачею — осмислений commit. У коді, YML, SQL і документації бажано уникати випадкових скорочень. Після перевірки — push.</syntaxhighlight> 
Код має бути:
git config --global user.email "ваша_електронна_пошта@example.com"

== Коміти ==

Небажано.</span>
|}

getmaster: true

Для списку компонент здатна використовуватися скрипт `auto_update`.</span> Воно має бути робочим dev-контуром, де можна безпечно розробляти, перевіряти й готувати зміни.=== Що таке рекомендації для розробників K2? ===
|-
| '''Ознака готовності.''' <span style="color:#2e7d32;">Розробник K2 має мислити не “як зробити кнопку”, а “який бізнес-процес ця кнопка змінює”. Розробник має враховувати права доступу на кількох рівнях:

Потрібно правильно описати `select`, `fields`, DropDown-поля, master-detail-зв’язки, кнопки `condition`, права доступу, ширини колонок, пошук і сортування. Призначення

Рекомендації для документів

Третя помилка — створювати новий довідник замість використання спільного. `forms.py` — за форми.

Висновок. Більшість проблем у ERP-розробці виникає не через складний код, а через відсутність дисципліни: прав, тестів, версій, документації та розуміння процесу.

Основні принципи розробки K2

K2Grid здатна описувати таблиці через YML-файли. Якщо з назви неясно, що змінилося, технічна підтримка стає складнішою. Тестування в K2 має перевіряти не тільки запуск сторінки, а повний бізнес-сценарій. Він має бути зручним для щоденної роботи. |-

Перевага K2Grid.

YML-опис дає можливість стандартизувати таблиці, зменшити дублювання коду й швидше створювати бізнес-інтерфейси. Погані приклади: Критично. Не можна вважати компонент готовим після push або завантаження на сервер оновлень. __pycache__ }

</syntaxhighlight>

detile: document_rows

Рекомендації для junior-розробника K2

  • не робити зайвих запитів;
  • не тягнути всі інформаційні дані без фільтрів;
  • використовувати пагінацію;
  • оптимізувати SQL;
  • додавати індекси там, де потрібно;
  • не перевантажувати dashboard;
  • не робити важкий експорт без обмежень;
  • перевіряти роботу на великих таблицях;
  • уникати зайвих JOIN без потреби;
  • логувати повільні або проблемні операції. Код має бути зрозумілим, компонент — документованим, інтерфейс — зручним, база даних — чистою, а оновлення версій — перевіреним. aaa
Технічний акцент. Розробник K2 функціонує на перетині коду, бази даних, бізнес-логіки, інтерфейсу, прав доступу та процесів підприємства. 
* `date`;
* `datetime`;
* `checkbox`;
* `DropDown`;
* `condition`;
* текстові поля;
* числові поля;
* службові поля;
* приховані ID;
* кнопки-дії.

SQL і довідники

git remote add origin http://git.corp2.eu/k2erp/python/k2/base/site/k2site.git

ERP функціонує з великими обсягами даних. ERP — це документи, довідники, залишки, платежі, договори, фінансовий блок, складський облік, клієнти, задачі, маршрути погодження, доступи, звіти, інтеграції й відповідальність за інформаційні дані. Middle-розробник має вміти будувати повноцінні модулі: 
== Див. так само ==
== Меню компонентів ==
Потрібно підготувати:
<syntaxhighlight lang="text">
{| class="wikitable" style="width:100%; background:#fff3e0;"
У K2 розробник має розуміти не тільки синтаксис мови програмування, а й предметну область. |}

Приклад `show_for`:

 elmsuffix: " %"

version = "2.0.4.43"

123
== Git-дисципліна ==
{| class="wikitable" style="width:100%; background:#e3f2fd;"

Для Python-розробки в K2 інтуїтивно використовувати PyCharm. {| class="wikitable" style="width:100%; background:#e3f2fd;"
 │ ├── schema/
'''Другий принцип — повторне використання.''' Якщо в K2 уже виступає як грид, форма, довідник, фільтр, механізм імпорту, експорту або доступів, потрібно використовувати стандартну логіку, а не писати власну копію. |-
| '''Порада junior.''' <span style="color:#1565c0;">Спочатку навчіться добре робити довідники, гриди, форми й права.<syntaxhighlight lang="text">

== Безпека розробки ==

[[Категорія:PHP]]

== Поля у K2Grid ==

* проєктувати модулі;
* визначати структуру БД;
* обирати правильні компоненти;
* контролювати продуктивність;
* проєктувати інтеграції;
* створювати reusable-рішення;
* перевіряти код інших;
* формувати стандарти;
* думати про оновлення версій;
* зменшувати технічний борг;
* навчати молодших розробників. Добра назва зменшує потребу в зайвих коментарях.<syntaxhighlight lang="text">
'''Рекомендації для розробників K2''' описують, як створювати модулі, компоненти, гриди, форми, документи, довідники, звіти, інтеграції й оновлення версій так, щоб вони були підтримуваними, безпечними, документованими й сумісними з екосистемою K2.== Версії компонентів ==
eval "$(ssh-agent -s)"
== Тестові домени deb1-deb3 ==
 exp: (false)
Для довідників критично:
Типова робота:
[[Категорія:Розробка веб-інтерфейсів K2]]
<syntaxhighlight lang="text">

update
|-
| '''Порада.''' <span style="color:#2e7d32;">Назва має пояснювати зміст. {| class="wikitable" style="width:100%; background:#fff3e0;"
<syntaxhighlight lang="yaml">
== розробка програмного забезпечення для магазину доповнень K2 ==
Розробник має врахувати:
{| class="wikitable" style="width:100%; background:#e8f5e9;"

Тестові домени потрібні, щоб перевірити нову версію компоненти до використання в ширшому середовищі. Для завантаження компонентів у систему оновлення версій використовуються конфігурація в каталозі:
{| class="wikitable" style="width:100%; background:#e3f2fd;"
python git_cmd.py pull
.git

Добра форма має:

Тестування

order by name

python git_cmd.py status <syntaxhighlight lang="python"> <syntaxhighlight lang="yaml"> Для інтеграції потрібно описати:

Отримано з https://wiki.kyiv.ua/index.php?title=Рекомендації_для_розробників_K2&oldid=805