Merge branch 'develop' into dev_29674_bis

.github/CONTRIBUTING.md

@@ -1,20 +1,21 @@
 How to contribute to Dolibarr
 =============================
 
-Send a Bug reports or a Feature request
+Submit a Bug report or a Feature request
 ---------------------------------------
 
-<a name="not-a-support-forum"></a>*Note*: **GitHub Issues is not a support forum.** If you have questions about Dolibarr / need help on using the software, please use [the forums](https://www.dolibarr.org/forum.php). Forums exist in different languages.
+<a name="not-a-support-forum"></a>*Note*: **GitHub Issues is not a support forum.**  
+If you have questions about Dolibarr or need help on using the software, please use [the forums](https://www.dolibarr.org/forum.php). Forums exist in different languages.
 
-Issues to inform about a bug or a development trouble, like requests for a new feature, are managed on [GitHub](https://github.com/Dolibarr/dolibarr/issues).
-Default **language here is English**. So please prepare your contributions in English (we recommand using an online translation service if you don't know English).
+Issues to inform about a bug or a development trouble and requests for a new feature, are managed on [GitHub](https://github.com/Dolibarr/dolibarr/issues).
+Default **language here is English**. So please prepare your contributions in English (we recommend using an online translation service if you don't speak English).
 
-1. Please [use the search engine](https://help.github.com/articles/searching-issues) to check if nobody's already reported your problem.
+1. Please [use the search engine](https://help.github.com/articles/searching-issues) to check if anyone else has already reported your issue.
 2. [Create an issue](https://help.github.com/articles/creating-an-issue). Choose an appropriate title. Prepend appropriately with Bug or Feature Request.
 3. Tell us the version you are using!   (look at  /htdocs/admin/system/dolibarr.php?  and check if you are using the latest version) 
 4. Write a report with as much detail as possible (Use [screenshots](https://help.github.com/articles/issue-attachments) or even screencasts and provide logging and debugging information whenever possible).
 5. Delete unnecessary submissions.
-6. **Check your Message at Preview before sending.**
+6. **Check your Message at Preview before submitting.**
 
 
 
@@ -23,12 +24,12 @@ Default **language here is English**. So please prepare your contributions in En
 Submit code
 ---------------------
 
-This process describes how a Developer can submit code to the project so it can be analysezd and validated by the Merger (we call this a Pull Request).
+This process describes how a Developer can submit code to the project so it can be analyzed and validated by the PR Maintainer (we call this a Pull Request).
 
 Definition:
-- The Developer: is the human knowing the development language of the application that want to change some part of the code by making changement on the sources of the project.
-- The Merger: is the human knowing the development and check that the code submitted for approbation is correct to validate it, in other word, the Merger is the approbator of commits. 
-- The Releaser: is the human that validates that there a freeze/beta version is ok to be released officialy as a stable version.
+- Developer: is the human knowing the development language of the application that wants to change some part of the code by modifying the sources of the project.
+- PR Maintainer: is the human knowing the development language and code who checks that the code submitted for approbation is correct to validate it, in other words, the PR Maintainer is the approbator of commits. 
+- Release Maintainer: is the human that validates that a freeze/beta version is ok to be released officially as a stable version.
 
 
 ### Basic workflow
@@ -42,15 +43,16 @@ As the Developer:
 5. Commit and push your changes.
 6. [Make a pull request](https://help.github.com/articles/creating-a-pull-request).
 
-As the Merger:
+As the PR Maintainer:
 
-7. The Merger will check and say if he approves or not the commits. During this step, the Merger can modify your own code to make it valid for appobation or ask you to make the change yourself. For this the Merger may add commits himself. Depending on the tools used (can be done from github directly orfrom an IDE), such commits may be done directly after having validating your PR (for example to complete it).
+7. The PR Maintainer will check and decide if he approves or not the commits. During this step, the PR Maintainer can modify your own code to make it valid for approbation or ask you to make the change yourself. For this the PR Maintainer may add commits to a PR. Depending on the tools used (can be done from github directly or from an IDE), such commits may be done directly after validating your PR (for example to complete it).
 
-Note: Of course, the Merger, does not need to ask to himself if he is ok to validate a commit he did himself. This is a reason why the Merger can validate commits he did directly without passing by the approbation process described for the Developer.
+As the Release Maintainer:
 
-As the Releaser:
+8. A tag will be added to take a snapshot of the code with all the changes approved by PR Maintainers, when ready to do a release.
 
-8. A tag will be added to take a photo of the code will all the changes approved by the Merger, when he decide to do a release.
+
+Note: Project leader(Master Yoda and BDFL) retains all above roles and can directly commit to the project without a PR. Of course anyone can check commit history and comment!
 
 
 <span id="branches" name="branches"></span>
@@ -59,21 +61,23 @@ As the Releaser:
 
 Unless you're fixing a bug, all pull requests should be made against the *develop* branch.
 
-If you're fixing a bug, it is preferred that you cook your fix and pull request it against an oldest version affected.
+If you're fixing a bug, it is preferred that you make a pull request against the oldest version affected.
 
-We recommend to push it into N - 2 for N the latest version available, if not possible into version N - 1, and finally into develop.
-This is just a recommendation, currently, if you push a bug fix on a very old version, it is still merged and propagated into higher versions. 
+We recommend to push it into N - 2 where N is the latest version available, if not possible into version N - 1, and finally into develop.
 
 The rule N - 2 is just a tip if you don't know which version to choose to get the best compromise between ease of correction and number of potential beneficiaries of the correction.
 
+If you push a bug fix on a very old version it is still going to be merged and propagated into newer versions(choose wisely because old versions depend on old deprecated/unsupported versions of PHP and external libraries). 
+
+
 
 ### General rules
 
 - As the Developer, please don't edit the ChangeLog file. This file is generated from all commit messages during the release process by the Project releaser.
 
-- As the Developer: Do not submit changes into files xx_XX/afile.lang. They are language files and are updated automatically by sync from Transifex. If you need to add a new language file, just add it for the en_US language.
+- As the Developer: Do not submit changes into files xx_XX/afile.lang. They are language files and are updated/synced automatically from Transifex. If you need to add a new language file, just add it for the en_US language.
 
-- As the Releaser: The releaser will decide to make a new release as soon as the planning of the release is reached and the code in the branch to release reach the status "No more known serious bug known". 
+- As the Release Maintainer: The Release Maintainer will decide to make a new release as soon as the planning of the release is reached and the code in the branch to release reach the status of "No more known serious bugs". 
 
 
 <a name="commits"></a>
@@ -135,9 +139,9 @@ FIX|Fix #456 Short description (where #456 is number of bug fix, if it exists. I
 or
 CLOSE|Close #456 Short description (where #456 is number of feature request, if it exists. In upper case to appear into ChangeLog)
 or
-NEW|New|QUAL|Qual|PERF|Perf Short description (In upper case to appear into ChangeLog, use this if you add a feature not tracked, otherwise use CLOSE #456)
+NEW|New|QUAL|Qual|PERF|Perf Short description (In upper case to appear into ChangeLog, use this if you add a feature not tracked, otherwise use CLOSE #xxx)
 or
-Short description (when the commit is not introducing feature nor closing a bug)
+Short description (when the commit is not introducing a feature nor closing a bug)
 
 Long description (Can span across multiple lines).
 </pre>
@@ -154,24 +158,24 @@ a process to follow to optimize the chance to have PRs merged efficiently...
 
 * When submitting a pull request, use same rule as [Commits](#commits) for the message. If your pull request only contains 1 commit, GitHub will be smart enough to fill it for you. Otherwise, please be a bit verbose about what you're providing.
 
-* A screenshot will be always required for any PR of change/addition of a GUI behaviour.
+* A screenshot will be always required for any PR of change/addition of a GUI behavior.
 
 Also, some code changes need a prior approbation:
 
-* if you want to include a new external library (into htdocs/includes directory), please ask before to the core project manager (mention @dolibarr-jedi in your issue) to see if such a library can be accepted.
+* if you want to include a new external library (into htdocs/includes directory), please contact the core project manager first (mention @dolibarr-jedi in your issue) to see if such a library can be accepted.
 
 * if you add new tables or fields, you MUST first submit a standalone PR with the data structure changes you plan to add/modify (and only data structure changes). Start development only once this data structure has been accepted.
 
 Once a PR has been submitted, you may need to wait for its integration. It is common that the project leader let the PR open for a long delay to allow every developer discuss about the PR (A label is added in such a case).
 
 If the label of PR start with "Draft" or "WIP" (Work In Progress), it will not be analyzed for merging until you change the label of the PR (but it can be analyzed for discussion).
 
-If your PR has errors reported by the Continuous Integration Platform, it means your PR is not valid and nothing will be done with it. It will be kept open to allow developers to fix this, or it may be closed several month later. Don't expect anything on your PR if you have such errors, you MUST first fix the Continuous Integration error to have it taken into consideration.
+If your PR has errors reported by the Continuous Integration Platform, it means your PR is not valid and nothing will be done with it. It will be kept open to allow developers to fix this, or it may be closed several months later. Don't expect anything on your PR if you have such errors, you MUST first fix the Continuous Integration error to have it taken into consideration.
 
-If the PR is valid, and is kept open for a long time, a tag will also be added on the PR to describe the status of your PR and why the PR is kept open. By putting your mouse on the tag, you will get a full explanation of the tag/status that explain why your PR has not been integrated yet.
-In most cases, it gives you information of things you have to do to have the PR taken into consideration (for example a change is requested, a conflict is expected to be solved, some questions were asked). If you have a yellow, red flag of purple flag, don't expect to have your PR validated. You must first provide the answer the tag ask you. The majority of open PR are waiting an action of the author of the PR.
+If the PR is valid, and is kept open for a long time, a tag will also be added on the PR to describe the status of your PR and why the PR is kept open. By putting your mouse on the tag, you will get a full explanation of the tag/status that explains why your PR has not been integrated yet.
+In most cases, it gives you information of things you have to do to have the PR taken into consideration (for example a change is requested, a conflict is expected to be solved, some questions were asked). If you have a yellow, red flag of purple flag, don't expect to have your PR validated. You must first provide the answer the tag asks you. The majority of open PRs are waiting an action of the author of the PR.
 
-Statistics on Dolibarr project shows that 95% of submitted PR are reviewed and tagged. Average answer delay is also one of the best among Open source projects (just few days before having the Answer Tag set). This is one of the most important ratio of answered PR in Open Source world for a major project. Don't expect the core team to reach the 100%. 
+Statistics on Dolibarr project shows that 95% of submitted PRs are reviewed and tagged. Average answer delay is also one of the best among Open source projects (just few days before having the Answer Tag set). This is one of the most important ratio of answered PRs in Open Source world for a major project. Don't expect the core team to reach 100%. 
 A so high ratio is very rare on a so popular project and with the increasing popularity of Dolibarr, this ratio will probably decrease in future to a more common level.
 
 
@@ -186,9 +190,9 @@ All other translations are managed online at [Transifex](https://www.transifex.c
 
 Translations done on transifex are available in the next major release.
 
-Note: Sometimes, the source text (English) is modified. In such a case, the translation is reset. Transifex assume that if the original source
+Note: Sometimes, the source text (English) is modified. In such a case, the translation is reset. Transifex assumes that if the original source
 has changed, the translation is surely no more correct so must be done again. But old translation is not lost and you can use the tab "History"
-to retrieve all old translation of a source text, and restore the translation in one click with no need to retranslate it if there is no need to.
+to retrieve all old translations of a source text and restore the translation in one click with no need to retranslate it if there is no need to.
 
 
 ### Resources

.github/workflows/pre-commit.yml

@@ -32,7 +32,7 @@ jobs:
       # This is faster for a big repo.
       - name: Get all changed php files (if PR)
         id: changed-php
-        uses: tj-actions/changed-files@v44
+        uses: tj-actions/changed-files@v45
         if: env.gh_event == 'pull_request'
         with:
           files: |
@@ -72,7 +72,7 @@ jobs:
       # The next uses git, which is slow for a bit repo.
       # - name: Get all changed php files (if PR)
       #   id: changed-php
-      #   uses: tj-actions/changed-files@v44
+      #   uses: tj-actions/changed-files@v45
       #   if: env.gh_event == 'pull_request'
       #   with:
       #     files: |

.pre-commit-config.yaml

@@ -58,6 +58,12 @@ repos:
       # Check that there are no files that have are the same when uppercased (conflict on windows)
       - id: check-case-conflict
 
+  # Gitleaks is a SAST tool for detecting and preventing hardcoded secrets like passwords, api keys, and tokens in git repos
+  - repo: https://github.com/gitleaks/gitleaks.git
+    rev: v8.16.1
+    hooks:
+      - id: gitleaks
+
   # Beautify shell scripts
   - repo: https://github.com/lovesegfault/beautysh.git
     rev: v6.2.1

ChangeLog

@@ -22,6 +22,8 @@ The following changes may create regressions for some external modules, but were
 * Prepare your module for deprecation of triggers code XXX_INSERT to support also XXX_CREATE.
 * More class properties (with old name in french) are now deprecated in favor of the property name in english.
 * The json emulator dol_json_encode/decode() is removed. The native json PHP module must be enabled/available (this is the case by default with most PHP installation).
+* The experimental and deprecated module WebserviceClient is completely removed (SOAP technology is deprecated). May be replaced with the stable module Webhook.
+
 
 
 ***** ChangeLog for 20.0.0 compared to 19.0 *****