R: Створена сторінка: {{DISPLAYTITLE:Створення модулів K2 ERP}} {{SEO |title=Створення модулів K2 ERP — компоненти, Git, auto_update, setup.py, history.txt, k2update_push.py |description=Створення модулів K2 ERP — інструкція для розробників K2 Cloud ERP Python: структура компоненти, підключення репозиторію Git, робота через auto_update, ру...

2026-05-02T19:10:25Z

Створена сторінка: {{DISPLAYTITLE:Створення модулів K2 ERP}} {{SEO |title=Створення модулів K2 ERP — компоненти, Git, auto_update, setup.py, history.txt, k2update_push.py |description=Створення модулів K2 ERP — інструкція для розробників K2 Cloud ERP Python: структура компоненти, підключення репозиторію Git, робота через auto_update, ру...

Нова сторінка

{{DISPLAYTITLE:Створення модулів K2 ERP}}

{{SEO
|title=Створення модулів K2 ERP — компоненти, Git, auto_update, setup.py, history.txt, k2update_push.py
|description=Створення модулів K2 ERP — інструкція для розробників K2 Cloud ERP Python: структура компоненти, підключення репозиторію Git, робота через auto_update, ручне підключення компоненти, коміт змін, налаштування component-list.txt, ignore, token.txt, зміна версії в setup.py, опис змін у history.txt, завантаження компоненти через k2update_push.py і тестування на deb1-deb3.
|keywords=створення модулів K2 ERP, модулі K2 ERP, компоненти K2 ERP, K2 Cloud ERP Python, розробка K2 ERP, K2 ERP для розробників, auto_update K2 ERP, git_cmd.py, k2update_push.py, setup.py K2 ERP, history.txt K2 ERP, component-list.txt, token.txt, Git K2 ERP, PyCharm K2 ERP, компонента k2site, компонента k2adm, компонента k2update, deb1, deb2, deb3, сервер оновлення K2 ERP, K2 Cloud ERP, українська ERP
}}

'''Створення модулів K2 ERP''' — це процес розробки, підключення, версіонування, тестування та завантаження компонент у систему оновлення [[K2 ERP]] або [[K2 Cloud ERP]].

У технічній інструкції для розробників K2 Cloud ERP використовується термін '''компонента'''. У wiki-статтях для бізнес-користувачів це часто називають '''модулем K2 ERP''', але для розробника важливо розуміти: модуль у користувацькому сенсі зазвичай реалізується через одну або кілька компонент у коді.

Компонента може мати власний каталог, власний Git-репозиторій, файл версії, історію змін, список файлів для оновлення та правила ігнорування службових файлів. Для роботи зі списком компонент у проєкті використовується скрипт '''auto_update''', який копіюється в корінь проєкту на рівні з файлом '''app.py'''. У його файлі '''settings.py''' додаються потрібні компоненти, а команда '''python git_cmd.py clone''' клонує актуальні версії компонент і перейменовує каталоги поточних версій. :contentReference[oaicite:3]{index=3}

__TOC__

== Що таке модуль K2 ERP ==

'''Модуль K2 ERP''' — це функціональна частина системи, яка додає або розширює можливості платформи.

Для користувача модуль може виглядати як окремий напрям роботи: CRM, документообіг, склад, виробництво, фінанси, оновлення, сайт, адміністрування або інший функціональний блок.

Для розробника модуль зазвичай пов’язаний із компонентами в структурі проєкту. Компонента може мати окремий каталог у папці:

<pre>
components
</pre>

Наприклад:

<pre>
components/k2site
components/k2adm
components/k2update
</pre>

Компоненти можуть підключатися до віддалених Git-репозиторіїв, оновлюватися, комітитися, пушитися, версіонуватися й завантажуватися на сервер оновлення.

== Модуль і компонента: різниця для розробника ==

У бізнес-описах зазвичай говорять «модуль». У технічній інструкції розробника частіше використовується слово «компонента».

'''Модуль''' — це функціональна одиниця з погляду користувача.

'''Компонента''' — це технічна одиниця з погляду коду, Git-репозиторію, версії та системи оновлення.

Наприклад, користувацький модуль може складатися з кількох компонент, а одна компонента може забезпечувати частину функціональності більшого модуля.

== Передумови для створення модуля ==

Перед створенням або підключенням нового модуля потрібно мати локально розгорнутий робочий проєкт K2 Cloud ERP.

Згідно з інструкцією розробників, спочатку копіюється існуючий проєкт по FTP, потім у каталозі '''/K2CloudERP''' запускається '''first_run''' для налаштування параметрів віртуального середовища, після чого у файлі '''/K2CloudERP/cfg/k2/k2/k2cfg.py''' змінюється '''domain_protocol''' з '''https''' на '''http''', а додаток запускається через '''run.sh''' або '''run.bat'''. :contentReference[oaicite:4]{index=4}

Для Linux перший запуск:

<pre>
bash first_run.sh
</pre>

Для Windows:

<pre>
./first_run.bat
</pre>

Запуск додатку в Linux:

<pre>
bash run.sh
</pre>

Запуск додатку у Windows:

<pre>
./run.bat
</pre>

== Середовище розробки ==

Для розробки модулів K2 ERP використовується [[PyCharm]].

У Linux PyCharm можна встановити через snap:

<pre>
sudo rm /etc/apt/preferences.d/nosnap.pref
sudo apt update
sudo apt install snapd
sudo snap install pycharm-community --classic
pycharm-community
</pre>

Також можна завантажити архів із сайту JetBrains, розпакувати його, перейти в папку '''bin''' і запустити:

<pre>
./pycharm.sh
</pre>

Якщо виникає помилка запуску, встановлюється JRE/JDK:

<pre>
sudo apt update
sudo apt install default-jdk
</pre>

Після відкриття проєкту в PyCharm потрібно налаштувати Python Interpreter: у правому нижньому куті вибрати '''Python Interpreter''', далі '''Add new Interpreter''', у полі '''Location''' вказати шлях до папки '''venv''', а в полі '''Base Interpreter''' — шлях до виконуваного Python-файлу поточного середовища. :contentReference[oaicite:5]{index=5}

Ручна активація віртуального середовища в Linux:

<pre>
source venv/bin/activate
</pre>

У Windows:

<pre>
.\venv\Scripts\activate
</pre>

== Git для модулів K2 ERP ==

Для створення й підтримки модулів потрібен Git.

Встановлення Git у Linux:

<pre>
sudo apt update
sudo apt install git
</pre>

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

<pre>
git config --global user.name "Ваше Ім'я"
git config --global user.email "ваша_електронна_пошта@example.com"
</pre>

Для авторизації через SSH створюється ключ:

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

Потім запускається ssh-agent:

<pre>
eval "$(ssh-agent -s)"
</pre>

Ключ додається командою:

<pre>
ssh-add ~/.ssh/id_rsa
</pre>

Публічний ключ можна переглянути командою:

<pre>
cat ~/.ssh/id_rsa.pub
</pre>

Після цього ключ копіюється й додається у віддалений репозиторій. :contentReference[oaicite:6]{index=6}

== Варіант 1. Створення або підключення модуля через auto_update ==

Для списку компонент використовується скрипт:

<pre>
auto_update
</pre>

Каталог зі скриптом потрібно скопіювати в корінь проєкту на рівні з виконуваним файлом:

<pre>
app.py
</pre>

У технічній інструкції вказано такий шлях до каталогу auto_update:

<pre>
https://git.corp2.eu/k2erp/python/k2/base/client/auto_update
</pre>

Після копіювання потрібно перейти в каталог:

<pre>
cd auto_update
</pre>

Далі відкривається файл:

<pre>
settings.py
</pre>

У словник додаються ключі з потрібними компонентами. Повний список компонент знаходиться у файлі:

<pre>
settings_example.py
</pre>

Після налаштування виконується команда:

<pre>
python git_cmd.py clone
</pre>

Ця команда клонує актуальні версії компонент і перейменовує каталоги поточних версій компонент. :contentReference[oaicite:7]{index=7}

== Варіант 2. Підключення однієї компоненти вручну ==

Якщо потрібно підключити одну компоненту вручну, потрібно перейти в каталог цієї компоненти.

Наприклад, для компоненти '''k2site''':

<pre>
cd components/k2site
</pre>

Далі ініціалізується Git у поточній директорії:

<pre>
git init
</pre>

Створюється локальна гілка '''main''' і виконується перемикання на неї:

<pre>
git checkout -b main
</pre>

За потреби можна перемкнутися на іншу локальну гілку:

<pre>
git checkout master
</pre>

Далі додається віддалений репозиторій. Для прикладу '''k2site''':

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

Перевірка підключеного репозиторію:

<pre>
git remote -v
</pre>

Отримання даних із віддаленого репозиторію без зміни поточної робочої гілки:

<pre>
git fetch origin
</pre>

Отримання даних із віддаленого репозиторію з автоматичним об’єднанням із поточною локальною гілкою:

<pre>
git pull origin main
</pre>

Перевірка змін локальної копії компоненти:

<pre>
git status
</pre>

Такий підхід використовується, коли потрібно працювати не з усім списком компонент, а з конкретною компонентою. :contentReference[oaicite:8]{index=8}

== Структура нової компоненти ==

Нова компонента має бути розміщена в каталозі:

<pre>
components
</pre>

Типовий шлях:

<pre>
components/назва_компоненти
</pre>

Для нової компоненти бажано мати:

<pre>
setup.py
history.txt
.gitignore
</pre>

Також у компоненті можуть бути службові каталоги, Python-файли, шаблони, статичні файли, налаштування, міграції, документація й інші елементи залежно від призначення модуля.

Назва компоненти має бути зрозумілою, стабільною і не конфліктувати з існуючими компонентами.

== setup.py компоненти ==

Файл:

<pre>
setup.py
</pre>

використовується для опису версії компоненти.

Перед завантаженням нової версії компоненти потрібно змінити версію у файлі '''setup.py''' у корені каталогу компоненти. В інструкції розробників вказано, що змінюється рядок 5, поле '''version'''. Наприклад: :contentReference[oaicite:9]{index=9}

<pre>
version=2.0.4.43
</pre>

Також вказується тип версії:

<pre>
version_type='stable'
</pre>

або testing-версія:

<pre>
version_type='testing'
</pre>

'''stable''' використовується для стабільної версії.

'''testing''' або beta використовується для тестової версії.

== history.txt компоненти ==

Файл:

<pre>
history.txt
</pre>

містить опис змін компоненти.

Після зміни версії у '''setup.py''' потрібно додати опис змін у '''history.txt''' у корені каталогу компоненти. Опис додається одним рядком.

Приклад:

<pre>
2.0.4.43 - додавання додаткового поля в форму реєстрації
</pre>

Це потрібно для того, щоб було зрозуміло, що саме змінилося в новій версії компоненти. :contentReference[oaicite:10]{index=10}

== Коміт змін модуля через auto_update ==

Якщо використовується auto_update, коміт змін виконується автоматизовано.

Потрібно перейти в каталог:

<pre>
cd auto_update
</pre>

Клонування компонент із віддаленого сервера:

<pre>
python git_cmd.py clone
</pre>

Перевірка статусу:

<pre>
python git_cmd.py status
</pre>

Коміт змін:

<pre>
python git_cmd.py commit
</pre>

Отримання змін із віддаленого сервера:

<pre>
python git_cmd.py pull
</pre>

Пуш змін на віддалений репозиторій:

<pre>
python git_cmd.py push
</pre>

Ці команди наведені в інструкції як автоматичний спосіб роботи зі змінами компонент через auto_update. :contentReference[oaicite:11]{index=11}

== Ручний коміт змін модуля ==

Якщо зміни комітяться вручну, спочатку потрібно перевірити статус:

<pre>
git status
</pre>

Потім додати зміни:

<pre>
git add .
</pre>

Виконати коміт:

<pre>
git commit -m "Назва комміту"
</pre>

Запушити зміни на віддалений репозиторій:

<pre>
git push
</pre>

Під час подальшої роботи зміни з віддаленого репозиторію отримуються командою:

<pre>
git pull
</pre>

Цей ручний сценарій також наведений у технічній інструкції розробників. :contentReference[oaicite:12]{index=12}

== Налаштування завантаження модуля на сервер оновлення ==

Після створення або зміни компоненти потрібно налаштувати завантаження на сервер оновлення.

Для цього відкривається папка:

<pre>
builder/config
</pre>

У файлі:

<pre>
component-list.txt
</pre>

потрібно додати список компонент, які будуть завантажуватися на сервер оновлення.

Кожна компонента додається з нового рядка.

Приклад:

<pre>
components/k2update
components/k2adm
components/k2site
</pre>

Саме такий приклад наведений в інструкції розробників. :contentReference[oaicite:13]{index=13}

== Налаштування ignore для компоненти ==

У папці:

<pre>
builder/config/ignore
</pre>

потрібно створити файл із назвою компоненти.

Наприклад:

<pre>
k2site.txt
</pre>

У цей файл додаються файли й папки, які не потрібно завантажувати на сервер оновлення.

Приклад:

<pre>
__pycache__
.gitignore
.git
ej2.min.js
</pre>

Це потрібно, щоб у пакет оновлення не потрапляли службові файли, локальні Git-дані, кеші або файли, які не мають бути доставлені на сервер оновлення. :contentReference[oaicite:14]{index=14}

== token.txt для сервера оновлення ==

У файлі:

<pre>
token.txt
</pre>

потрібно додати токен доступу до сервера оновлення.

Цей токен використовується під час завантаження компонент у систему оновлення.

Файл із токеном не можна передавати стороннім особам, публікувати в репозиторії або зберігати в неконтрольованому місці.

== Завантаження нової версії модуля в систему оновлення ==

Для завантаження нової версії компоненти потрібно виконати кілька дій.

Спочатку змінити версію у файлі:

<pre>
setup.py
</pre>

Потім додати опис змін у файл:

<pre>
history.txt
</pre>

Далі перейти в корінь додатку на рівні з виконуваним файлом:

<pre>
app.py
</pre>

В інструкції використовується команда:

<pre>
cd k2
</pre>

Після цього компоненти, додані у файлі:

<pre>
builder/config/component-list.txt
</pre>

завантажуються командою:

<pre>
python k2update_push.py
</pre>

Це основна команда для завантаження нової версії компоненти в систему оновлення. :contentReference[oaicite:15]{index=15}

== Тестування модуля на deb1-deb3 ==

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

<pre>
deb1
deb2
deb3
</pre>

Після оновлення потрібно протестувати функціонал.

Тестування має підтвердити, що компонента працює коректно, нові зміни не ламають існуючі сценарії, залежності не конфліктують, а модуль можна готувати до подальшого використання.

Цей крок також є завершальним пунктом інструкції розробників. :contentReference[oaicite:16]{index=16}

== Типовий порядок створення нового модуля K2 ERP ==

{| class="wikitable" style="width:100%;"
! Крок
! Дія
|-
| 1
| Локально розгорнути робочий проєкт K2 Cloud ERP.
|-
| 2
| Відкрити проєкт у PyCharm і налаштувати Python Interpreter.
|-
| 3
| Встановити й налаштувати Git.
|-
| 4
| Створити каталог нової компоненти в папці components або підключити існуючу компоненту.
|-
| 5
| Підключити віддалений Git-репозиторій вручну або через auto_update.
|-
| 6
| Розробити функціональність модуля.
|-
| 7
| Перевірити зміни локально через запуск K2 Cloud ERP.
|-
| 8
| Закомітити зміни через auto_update або вручну.
|-
| 9
| Додати компоненту в builder/config/component-list.txt.
|-
| 10
| Налаштувати ignore-файл для компоненти.
|-
| 11
| Змінити версію в setup.py.
|-
| 12
| Додати опис змін у history.txt.
|-
| 13
| Завантажити компоненту через python k2update_push.py.
|-
| 14
| Оновити компоненту на deb1-deb3 і протестувати функціонал.
|}

== Мінімальний чеклист компоненти ==

{| class="wikitable" style="width:100%;"
! Елемент
! Для чого потрібен
|-
| Каталог у components
| Місце розміщення коду компоненти.
|-
| Git-репозиторій
| Версіонування, спільна робота й передача змін.
|-
| setup.py
| Версія компоненти та тип версії: stable або testing.
|-
| history.txt
| Опис змін у новій версії.
|-
| component-list.txt
| Список компонент, які завантажуються на сервер оновлення.
|-
| ignore-файл
| Список файлів і папок, які не потрібно завантажувати.
|-
| token.txt
| Токен доступу до сервера оновлення.
|-
| k2update_push.py
| Скрипт завантаження компонент у систему оновлення.
|-
| deb1-deb3
| Тестові домени для перевірки оновленої компоненти.
|}

== Типові помилки під час створення модулів ==

Найчастіша помилка — створити код компоненти, але не підключити її до Git-репозиторію або не додати в список компонент для оновлення.

Друга помилка — змінити код, але не оновити версію в '''setup.py'''.

Третя помилка — не додати опис змін у '''history.txt'''. Через це складніше зрозуміти, що саме було змінено в новій версії.

Четверта помилка — не налаштувати ignore-файл. У такому разі на сервер оновлення можуть потрапити зайві службові файли, наприклад '''__pycache__''' або '''.git'''.

П’ята помилка — не протестувати компоненту на тестових доменах '''deb1-deb3''' після завантаження.

== Безпека під час роботи з модулями ==

Під час створення модулів K2 ERP потрібно уважно ставитися до доступів, токенів і репозиторіїв.

Файл:

<pre>
token.txt
</pre>

містить токен доступу до сервера оновлення, тому його не можна публікувати у відкритому доступі.

SSH-ключі, паролі, токени, адреси внутрішніх репозиторіїв і службові доступи мають зберігатися контрольовано.

Перед завантаженням компоненти потрібно перевірити, що в пакет оновлення не потрапляють локальні файли, кеші, тестові дані, тимчасові конфігурації або приватні ключі.

== Коротко ==

{| class="wikitable" style="width:100%;"
! Питання
! Відповідь
|-
| Що створюється?
| Модуль або компонента K2 ERP.
|-
| Де розміщується код?
| У каталозі components.
|-
| Як підключати компоненти?
| Через auto_update або вручну через Git.
|-
| Як клонувати компоненти через auto_update?
| python git_cmd.py clone
|-
| Як перевірити статус?
| git status або python git_cmd.py status
|-
| Як закомітити зміни?
| git commit -m "Назва комміту" або python git_cmd.py commit
|-
| Де змінюється версія?
| У файлі setup.py.
|-
| Де описуються зміни?
| У файлі history.txt.
|-
| Де задається список компонент для оновлення?
| У builder/config/component-list.txt.
|-
| Як завантажити компоненту?
| python k2update_push.py
|-
| Де тестувати?
| На тестових доменах deb1, deb2 і deb3.
|}

== Див. також ==

* [[K2 ERP]]
* [[K2 Cloud ERP]]
* [[Розгортання K2 Cloud ERP Python для розробників]]
* [[Встановлення K2 ERP]]
* [[K2 ERP для Linux]]
* [[PyCharm]]
* [[Git]]
* [[GitLab]]
* [[Розробка K2 ERP]]
* [[Компоненти K2 ERP]]
* [[Оновлення K2 ERP]]
* [[K2 Cloud Ядро]]
* [[API K2 ERP]]
* [[Права доступу K2 ERP]]
* [[Безпека ERP]]

[[Категорія:Створення модулів K2 ERP]]
[[Категорія:Модулі K2 ERP]]
[[Категорія:Компоненти K2 ERP]]
[[Категорія:Розробка K2 ERP]]
[[Категорія:K2 ERP для розробників]]
[[Категорія:K2 ERP Python]]
[[Категорія:K2 ERP]]
[[Категорія:K2 Cloud ERP]]
[[Категорія:K2 Cloud Ядро]]
[[Категорія:PyCharm]]
[[Категорія:Git]]
[[Категорія:GitLab]]
[[Категорія:Оновлення K2 ERP]]
[[Категорія:API K2 ERP]]
[[Категорія:Безпека ERP]]
[[Категорія:Українська ERP]]
[[Категорія:ERP-системи]]
[[Категорія:Корпоративна Wiki]]

Створення модулів K2 ERP - Історія редагувань