Jingga/jsOMS
1
0
Fork 0
mirror of https://github.com/Karaka-Management/jsOMS.git synced 2026-01-10 17:38:41 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

bump

Browse Source
This commit is contained in:
Dennis Eichhorn 2024-02-28 05:09:14 +00:00
parent f563301e29
commit 3c830054bd
12 changed files with 93 additions and 366 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
.github/FUNDING.yml vendored
View File

@ -1,12 +0,0 @@
# These are supported funding model platforms
github: # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2]
patreon: # orange_management
open_collective: # Replace with a single Open Collective username
ko_fi: # Replace with a single Ko-fi username
tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
liberapay: # Replace with a single Liberapay username
issuehunt: # Replace with a single IssueHunt username
otechie: # Replace with a single Otechie username
custom: ['https://paypal.me/orangemgmt']

35
.github/dev_bug_report.md vendored
View File

@ -1,35 +0,0 @@
---
name: Dev Bug Report
about: Create a report to help us improve
title: ''
labels: stat_backlog, type_bug
assignees: ''
---
# Bug Description
A clear and concise description of what the bug is.
# How to Reproduce
Steps to reproduce the behavior:
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error
## Minimal Code Example
```js
// your code ...
```
# Expected Behavior
A clear and concise description of what you expected to happen.
# Screenshots
If applicable, add screenshots to help explain your problem.
# Additional Information
Add any other context about the problem here.

18
.github/dev_feature_request.md vendored
View File

@ -1,18 +0,0 @@
---
name: Dev Feature Request
about: Suggest an idea for this project
title: ''
labels: stat_backlog, type_feature
assignees: ''
---
# What is the feature you request
* A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
* A clear and concise description of what you want to happen.
# Alternatives
A clear and concise description of any alternative solutions or features you've considered.
# Additional Information
Add any other context or screenshots about the feature request here.

46
CODE_OF_CONDUCT.md
View File

@ -1,46 +0,0 @@
# Contributor Covenant Code of Conduct
## Our Pledge
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at spl1nes.com@gmail.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
[homepage]: http://contributor-covenant.org
[version]: http://contributor-covenant.org/version/1/4/

196
CONTRIBUTING.md
View File

@ -1,196 +0,0 @@
## Development environment
The setup and configuration of the development environment is in the hands of every developer themselves. However, it is recommended to follow the setup instructions in the [Developer-Guide](https://github.com/Karaka-Management/Developer-Guide/blob/develop/general/setup.md).
## Code of conduct
Every organization member and contributor to the organization must follow the [Code of Conduct](../Policies%20&%20Guidelines/Code%20of%20Conduct.md).
## Becoming a contributor
For public repositories you can immediately start by creating forks and pull requests. For private repositories which are necessary to setup the complete developer environment, feel free to request access. Please not that we may not immediately give you access to private repositories and instead will give you smaller tasks regarding public repositories. Please contact info@jingga.app for more details. (**R1**)
For all contributions our [Contributor License Agreement "CLA"](https://github.com/Karaka-Management/Organization-Guide/blob/master/Processes/HR/Hiring/Individual%20Contributor%20License%20Agreement.md) comes into effect. (**R2**)
## Code changes
### Topics / Tasks / Todos
Generally, the development philosophy is result orientated. This means that anyone can propose tasks, pick up existing tasks or right away implement their code changes. However, implementing code changes without consulting with a senior developer in advance has a much higher risk of code changes not getting admitted. The easiest way to discuss a code change idea in advance are the github [issues](https://github.com/Karaka-Management/Karaka/issues) or [discussions](https://github.com/Karaka-Management/Karaka/discussions).
Developers are encouraged to pick open tasks with high priorities according to their own skill level. Senior developers may directly assign tasks to developers based on their importance. New developers may find it easier to start with a task that has a low priority as they often also have a lower difficulty.
Open tasks can be found in the project overview: [Todos](https://github.com/orgs/Karaka-Management/projects/10)
Tasks currently in development are prefixed in the priority column with an asterisk `*` and a name tag in the task description of the developer who is working on the task.
The open tasks are reviewed once a month by a senior developer. The senior developer updates the project overview if necessary and requests feedback regarding development status of important tasks under development. During this process important tasks may also get directly assigned to developers. This review is performed on a judgmental bases of the senior basis.
### Quality
#### Code style
Code changes must follow the [style guidelines](https://github.com/Karaka-Management/Developer-Guide/tree/develop/standards) (**R3**). Additionally, the automatic code style inspection tools must return no errors, failures or warnings. Developers should test their changes with inspection tools and configurations mentioned in the [inspection documentation](https://github.com/Karaka-Management/Developer-Guide/blob/develop/quality/inspections.md) in advance before submitting them for review. (**R4**)
In rare cases errors, failures or warnings during the automatic inspection are acceptable. Reasons can be for example special cases which are difficult automatize or must be individually configured in the inspection settings. If this is the case for a code change and if inspection configuration changes are necessary are decided by the senior developer performing the code review. (**R5**)
Automated checks which are run during the review process (**R4**):
```sh
php ./vendor/bin/phpcs ./ --standard="Build/Config/phpcs.xml"
php ./vendor/bin/php-cs-fixer fix ./ --config=Build/Config/.php-cs-fixer.php --allow-risky=yes
php ./vendor/bin/phpcbf --standard=Build/Config/phpcs.xml ./
php ./vendor/bin/rector process --dry-run --config Build/Config/rector.php ./
npx eslint ./ -c ./Build/Config/.eslintrc.json
```
#### Tests
Code changes must follow the inspection guidelines (i.e. code coverage) mentioned in the [inspection documentation](https://github.com/Karaka-Management/Developer-Guide/blob/develop/quality/inspections.md) (**R6**). Developers should test their changes with inspection tools and configurations mentioned in the [inspection documentation](https://github.com/Karaka-Management/Developer-Guide/blob/develop/quality/inspections.md) in advance before submitting them for review. (**R7**)
In rare cases it might be not possible to follow the inspection guidelines. In such cases the senior developer performing the code review may decide if the code change still gets accepted. (**R8**)
Automated tests which are run during the review process (**R7**):
```sh
php ./vendor/bin/phpunit -c tests/PHPUnit/phpunit_default.xml
php ./vendor/bin/phpstan analyse --no-progress -l 9 -c Build/Config/phpstan.neon ./
npx jasmine-node ./
./cOMS/tests/test.sh
```
Additional inspections which are run but might be ignored during the review depending on the use case are mentioned in the [inspection documentation](https://github.com/Karaka-Management/Developer-Guide/blob/develop/quality/inspections.md) as other checks. (**R7**)
#### Performance
Developers should occasionaly check performance statistics. At this point no target metrics are defined.
Since the primary application is a web based application a similar tool as the Google lighthouse tool can be used to inspect the application for best practicies which can significantly improve the application performance. The sitespeed.io tool shows potential performance improvements and slow pages. With the php trace and profiler enabled in the `php.ini` file the VM automatically generates profiling and trace reports for every web request. These can be found in the webgrind logs directory and inspected in webgrind and dropped into the trace visualizer for a flame chart visualization. With mysqldumpslow you can inspect slow sql queries which may need optimization.
1. Automatic trace and benchmark generation with every web request in `/var/www/html/webgrind/Logs`
2. Webgrind view `http://vm_ip:82`
3. Trace visualization `http://vm_ip:81`
1. Download the latest trace from `http://vm_ip:82/Logs`
2. Drag and drop that downloaded `*.xt` file in the trace visualizer
4. `sitespeed.io ./Build/Helper/Scripts/sitespeedDemoUrls.txt -b chrome --outputFolder /var/www/html/sitespeed`
5. Slow query inspection.
```sh
mysqldumpslow -t 10 /var/log/mysql/mysql-slow.log
mysqldumpslow -t 10 -s l /var/log/mysql/mysql-slow.log
```
#### Code review
In addition to the automatic code review performed by the various inspection tools such as (phpcs, phpstan, phpunit, eslint and custom scripts) a senior developer must check the proposed code change before it is merged with the respective `develop` branch. Only upon the approval by the reviewer a code change requests gets merged as no other developers have permission in the software to make such code merges.
In case a code change request is not approved the reviewer states the reason for the decision, this may include some tips and requests which will allow the contributor to make improvements so that the code change may get approved.
If the code reviewer only finds minor issues with the proposed code change the reviewer may make small changes to the proposed code change and inform the contributor to speed up the implementation process. Code reviewers are encouraged to do this with new contributors to avoid long iteration processes and to not discourage new developers. However, communication is key and severe issues with code change requests or if the contributor already made multiple code change requests in the past the reviewer should not implement the improvements by himself and rather decline the code change requests with his reasoning. (**R5**+**R8**)
#### Demo
Some code changes may also require changes or extensions in the demo setup scripts. The demo setup script try to simulate a real world use case by generating and modifying mostly random data. This is also a good way to setup and “manually” test the code changes in a larger picture. The demo setup script can be found in the [demoSetup](https://github.com/Karaka-Management/demoSetup) repository. The demo setup script takes a long time due to the large amount of user input simulated data which is generated. Therefore it is recommended to run this only sporadically. (**R9**)
```sh
sudo -u www-data php -dxdebug.remote_enable=1 -dxdebug.start_with_request=yes -dxdebug.mode=coverage,develop,debug demoSetup/setup.php
```
#### Documentation
Occasionally new code or code changes also require new documentation or documentation changes. Developers should make sure that the new code is also reflected in the existing documentation ([Developer-Guide](), [User-Guide]() and/or module documentation) or if additional documentation is necessary.
#### Improvements, features, bugs
If a developer (or employee in general) has an idea for an improvement, feature or finds a potential bug it should be reported at https://github.com/Karaka-Management/Karaka/issues. A senior developer has to check these issues and decide how to proceed with them. The decision how to proceed with the issue must be explained by the senior developer as a response in the issue. Possible steps are:
* Accept the issue and put the task into the [Todos](https://github.com/orgs/Karaka-Management/projects/10)
* Dismiss the issue with an explanation
### Release flow
In case SCSS/CSS or JS files got changed they must get re-built locally before comitting the code change:
```sh
npx esbuild Web/Backend/js/backend.js --bundle --outfile=Install/Application/Backend/js/backend.min.js --minify
scss cssOMS/styles.scss > cssOMS/styles.css
```
For JS you may also use the shorthand command `npm run build`.
Code changes must be performed in a new branch. A new branch can be created with:
```sh
git checkout -b new-branch-name
```
The name of the branch can be chosen freely however it is recommended to follow the following branch naming conventions:
* `feature-*` for feature implementations
* `hotfix-*` for security related fixes/improvements
* `bug-*` for bug fixes
* `security-*` for security related fixes/improvements
* `general-*` for general improvements (i.e. documentation, code style & performance improvements)
```mermaid
%%{init: { 'gitGraph': {'mainBranchName': 'master'}} }%%
gitGraph
commit
branch hotfix-xxx
commit
checkout master
branch develop
checkout master
merge hotfix-xxx
checkout develop
branch bug-xxx
commit
commit
checkout hotfix-xxx
commit
checkout master
merge hotfix-xxx
checkout develop
merge bug-xxx
commit
checkout develop
branch feature-xxx
commit
commit
commit
checkout develop
merge feature-xxx
checkout master
merge develop
checkout develop
branch general-xxx
commit
checkout develop
merge general-xxx
branch security-xxx
commit
commit
checkout develop
merge security-xxx
checkout master
merge develop
```
The senior developer who performs the code review merges the change request into the `develop` branch after their successful code review. Unsuccessful reviews lead to change requests by the original developer, other developers who can make the requested changes, changes by the senior developer who performed the review, or dismissal of the changed code. (**R10**)
## Approved dependencies
### Customer dependencies
Developers may only rely on the dependencies defined in [Approved Customer Software]() when developing a solution. If new software should be added to this list or a different version is required developers should make a request with their team leader/head of department who forwards this requests if appropriate to the CTO and explain the reasoning for the different dependency needs. The CTO can decide if the dependency will be accepted. (**R11**)
### Developer dependencies
Developers may only rely on the dependencies defined in [IT Equipment & Software](). If new software should be added to this list or a different version is required developers should make a request with their team leader/head of department who forwards this requests if appropriate to the CTO and explain the reasoning for the different dependency needs. The CTO can decide if the dependency will be accepted. Changing the package managers such as `composer.json` or `package.json` is not allowed by anyone else than the CTO. (**R12**)
## Other related documents
* [Confidentiality Policy](../Policies%20&%20Guidelines/Confidentiality%20Policy.md)
* [Organization Activity Policy](../Policies%20&%20Guidelines/Organization%20Activity%20Policy.md)
* [Tutorials](./Development/Tutorials)

2
Message/Notification/App/AppNotification.js
View File

@ -62,7 +62,7 @@ export class AppNotification
};
const output = document.importNode(tpl.content, true);
output.querySelector('.log-msg').classList.add('log-msg-status-' + msg.status);
output.querySelector('.log-msg').classList.add('log-lvl-' + msg.status);
output.querySelector('.log-msg-content').innerHTML = msg.message;
output.querySelector('.close').addEventListener('click', function () {
this.parentNode.remove();

10
UI/Component/AdvancedSelect.js
View File

@ -1,3 +1,6 @@
import { jsOMS } from '../../Utils/oLib.js';
import { Request } from '../../Message/Request/Request.js';
// remote data
// select data could be template layout per element
// multi select
@ -5,8 +8,7 @@
// isn't this very similar to the advanced input? just a little different?
// maybe not...
import { jsOMS } from '../../Utils/oLib.js';
import { Request } from '../../Message/Request/Request.js';
/**
* Advanced input class.
*
@ -14,6 +16,10 @@ import { Request } from '../../Message/Request/Request.js';
* @license OMS License 2.0
* @version 1.0.0
* @since 1.0.0
*
* @todo Bind data to select options such as visible elements and data pre-fills.
* When an option is selected certain ui elements become visible and get filled out with default values.
* https://github.com/Karaka-Management/jsOMS/issues/104
*/
export class AdvancedSelect
{

63
UI/Component/Form.js
View File

@ -18,6 +18,13 @@ import { UriFactory } from '../../Uri/UriFactory.js';
* @license OMS License 2.0
* @version 1.0.0
* @since 1.0.0
*
* @todo Adding a template to the DOM should modify its id/generate a custom/random id for the added element
* for future handling as very often ids are required to identify and manage UI elements.
* https://github.com/Karaka-Management/jsOMS/issues/102
*
* @feature Auto update data changes in the backend (e.g. pull every x seconds, or use websockets for push)
* https://github.com/Karaka-Management/Karaka/issues/151
*/
export class Form
{
@ -1220,32 +1227,10 @@ export class Form
const statusCode = parseInt(xhr.getResponseHeader('status'));
if (statusCode === 200 || statusCode === null) {
if ((successInject = form.getSuccess()) !== null) {
successInject(response, xhr);
} else if (redirect !== null) {
fetch(UriFactory.build(redirect))
.then((response) => response.text())
.then((html) => {
document.documentElement.innerHTML = html;
if (window.omsApp.state) {
window.omsApp.state.hasChanges = false;
}
history.pushState({}, null, UriFactory.build(redirect));
/* This is not working as it reloads the page ?!
document.open();
document.write(html);
document.close();
*/
// @todo fix memory leak which most likely exists because of continuous binding without removing binds
window.omsApp.reInit();
})
.catch((error) => {
console.warn(error);
});
}
if ((successInject = form.getSuccess()) !== null
&& (statusCode === 200 || statusCode === null)
) {
successInject(response, xhr);
}
if (response.get('type') !== null) {
@ -1272,6 +1257,32 @@ export class Form
);
}
}
if (redirect !== null
&& (statusCode === 200 || statusCode === null)
) {
fetch(UriFactory.build(redirect))
.then((response) => response.text())
.then((html) => {
document.documentElement.innerHTML = html;
if (window.omsApp.state) {
window.omsApp.state.hasChanges = false;
}
history.pushState({}, null, UriFactory.build(redirect));
/* This is not working as it reloads the page ?!
document.open();
document.write(html);
document.close();
*/
// @todo fix memory leak which most likely exists because of continuous binding without removing binds
window.omsApp.reInit();
})
.catch((error) => {
console.warn(error);
});
}
});
if (window.omsApp.state) {

4
UI/Component/Tab.js
View File

@ -138,6 +138,10 @@ export class Tab
const fragments = fragmentString.split('&');
const fragLength = fragments.length;
// @bug The frontend loads the correct tab based on the provided fragment,
// but it is slow. Doing this in the backend can already fix this but the frontend implementation should be fixed,
// because this should be the job of the frontend.
// https://github.com/Karaka-Management/Karaka/issues/164
if (fragLength > 0 && fragmentString !== '') {
for (let i = 0; i < fragLength; ++i) {
const label = e.querySelector('label[for="' + fragments[i] + '"]');

50
UI/Component/Table.js
View File

@ -11,27 +11,37 @@ import { ResponseType } from '../../Message/Response/ResponseType.js';
* @version 1.0.0
* @since 1.0.0
*
* @todo Karaka/jsOMS#50
* Add basic table handling (no db and pagination)
* @feature Karaka/jsOMS#55
* Implement filtering and sorting based on backend
*
* @todo Karaka/jsOMS#55
* Implement filtering and sorting based on backend
* @feature Karaka/jsOMS#57
* Advanced filtering
* The current filtering implementation is only column by column connected with &&.
* Consider to implement a much more advanced filtering where different combinations are possible such as || &&, different ordering with parenthesis etc.
* This can be extremely powerful but will be complex for standard users.
* This advanced filtering should probably be a little bit hidden?
*
* @todo Karaka/jsOMS#57
* Advanced filtering
* The current filtering implementation is only column by column connected with &&.
* Consider to implement a much more advanced filtering where different combinations are possible such as || &&, different ordering with parenthesis etc.
* This can be extremely powerful but will be complex for standard users.
* This advanced filtering should probably be a little bit hidden?
* @feature Karaka/jsOMS#59
* Data download
* There is a small icon in the top right corner of tables which allows (not yet to be honest) to download the data in the table.
* Whether the backend should be queried for this or only the frontend data should be collected (current situation) should depend on if the table has an api endpoint defined.
*
* @todo Karaka/jsOMS#59
* Data download
* There is a small icon in the top right corner of tables which allows (not yet to be honest) to download the data in the table.
* Whether the backend should be queried for this or only the frontend data should be collected (current situation) should depend on if the table has an api endpoint defined.
* @feature Allow column drag/drop ordering which is also saved in the front end
*
* @todo Allow column drag/drop ordering which is also saved in the front end
* @feature Implement a filter highlight function.
* Either in forms or in tables, where the filter icon is highlighted, if a filter is defined.
* One solution could be to put an additional hidden filter checkbox in front of the filter icon and check for filter changes
* (bubble up) and then activate this hidden checkbox if a filter is defined.
* In CSS just define the filter icon as active/highlighted, if the hidden check box is active.
* This means we have two hidden checkboxes in front of the filter icon (one in case the filter menu is open = popup
* is visible and another one for highlighting the filter icon if a filter is defined).
* https://github.com/Karaka-Management/Karaka/issues/148
*
* @todo Save column visibility filter and apply that filter on page load
* @todo How to preserve form filter data to the next page?
* Not an issue, in the future we don't want to reload the whole page,
* but only exchange the table/list content with the backend response -> the header/filter will not get changed and
* remains as defined. This means for tables (maybe even forms?) to setup content replacement earlier than for other pages?!
* https://github.com/Karaka-Management/Karaka/issues/149
*/
export class Table
{
@ -198,11 +208,11 @@ export class Table
header.addEventListener('contextmenu', function (event) {
jsOMS.preventAll(event);
if (document.getElementById('table-context-menu') !== null) {
if (document.getElementById('table-ctx-menu') !== null) {
return;
}
const tpl = document.getElementById('table-context-menu-tpl');
const tpl = document.getElementById('table-ctx-menu-tpl');
if (tpl === null) {
return;
@ -210,7 +220,7 @@ export class Table
const output = document.importNode(tpl.content, true);
tpl.parentNode.appendChild(output);
const menu = document.getElementById('table-context-menu');
const menu = document.getElementById('table-ctx-menu');
const columns = header.querySelectorAll('td');
const length = columns.length;
@ -271,7 +281,7 @@ export class Table
static hideMenuClickHandler (event)
{
const menu = document.getElementById('table-context-menu');
const menu = document.getElementById('table-ctx-menu');
const isClickedOutside = !menu.contains(event.target);
if (isClickedOutside) {

2
UI/GeneralUI.js
View File

@ -258,7 +258,7 @@ export class GeneralUI
{
e = e !== null
? [e]
: document.getElementsByClassName('advancedInput');
: document.getElementsByClassName('advIpt');
const length = e.length;

21
Views/FormView.js
View File

@ -537,17 +537,15 @@ export class FormView
}
continue;
} else if (typeof elements[i].value !== 'undefined') {
value = elements[i].value;
} else if (elements[i].getAttribute('data-value') !== null) {
value = elements[i].getAttribute('data-value');
} else {
if (typeof elements[i].value !== 'undefined') {
value = elements[i].value;
} else if (elements[i].getAttribute('data-value') !== null) {
value = elements[i].getAttribute('data-value');
} else {
value = elements[i].innerHTML;
}
value = elements[i].innerHTML;
}
// handle array data (e.g. table rows with same name)
// handle array data (e.g. table rows with same name or name="myname[]")
if (Object.prototype.hasOwnProperty.call(data, id)) {
if (data[id].constructor !== Array) {
data[id] = [data[id]];
@ -561,7 +559,12 @@ export class FormView
for (const key in data) {
if (Object.prototype.hasOwnProperty.call(data, key)) {
formData.append(key, data[key] !== null && data[key].constructor === Array ? JSON.stringify(data[key]) : data[key]);
formData.append(
key,
data[key] !== null && data[key].constructor === Array
? JSON.stringify(data[key])
: data[key]
);
}
}