Merge branch 'develop' into fix-missing-state-in-openid-connect

.codeclimate.yml

@@ -4,10 +4,10 @@ languages:
   JavaScript: true
   PHP: true
 engines:
-  phpcodesniffer: true  
+  phpcodesniffer: true
 exclude_paths:
   - 'build/*'
   - 'dev/*'
   - 'doc/*'
   - 'test/*'
-  - 'htdocs/includes/*'
+  - 'htdocs/includes/*'

.editorconfig

@@ -22,3 +22,7 @@ indent_style = tab
 indent_style = tab
 [*.md]
 trim_trailing_whitespace = false
+[*.sql]
+indent_style = tab
+trim_trailing_whitespace = true
+indent_size = 4

.gitattributes

@@ -3,7 +3,7 @@
 * text=auto
 
 
-# Explicitly declare text files we want to always be normalized and converted 
+# Explicitly declare text files we want to always be normalized and converted
 # to native line endings on checkout.
 *.php text eol=lf
 *.pl text eol=lf
@@ -21,6 +21,7 @@
 *.yml text eol=lf
 *.yaml text eol=lf
 *.conf text eol=lf
+*.neon text eol=lf
 
 .bash_aliases text eol=lf
 

.github/CONTRIBUTING.md

@@ -7,18 +7,18 @@ Bug reports and feature requests
 <a name="not-a-support-forum"></a>*Note*: **GitHub Issues is not a support forum.** If you have questions about Dolibarr / need help using the software, please use [the forums](https://www.dolibarr.org/forum.php). Forums exist in different languages.
 
 Issues are managed on [GitHub](/~https://github.com/Dolibarr/dolibarr/issues). 
-Default **language here is english**. So please prepare your contributions in english.
+Default **language here is English**. So please prepare your contributions in English.
 
 1. Please [use the search engine](https://help.github.com/articles/searching-issues) to check if nobody's already reported your problem.
 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 informations whenever possible).
+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.**
 
 
 
-<a name="code"></a>Code
+<a name="code"></a>Submit code
 ---------------------
 
 ### Basic workflow
@@ -30,25 +30,30 @@ Default **language here is english**. So please prepare your contributions in en
 5. Commit and push your changes.
 6. [Make a pull request](https://help.github.com/articles/creating-a-pull-request).
 
+
 <span id="branches" name="branches"></span>
 ### Branches
 
 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 the oldest version affected that's still supported.
+If you're fixing a bug, it is preferred that you cook your fix and pull request it against an 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 officially support versions N, N − 1 and N − 2 for N the latest version available.
+The rule N - 2 is just a tip if you don't know which version to choose to get the best the best compromise between ease of correction 
+and number of potential beneficiaries of the correction.
 
-Choose your base branch accordingly.
 
 ### General rules
-Please don't edit the ChangeLog file. File will be generated from all commit messages during release process by the project manager.
+Please don't edit the ChangeLog file. This file is generated from all commit messages during release process by the project manager.
+
 
 ### <a name="commits"></a>Commits
 Use clear commit messages with the following structure:
 
-```
+```plaintext
 [KEYWORD] [ISSUENUM] DESC
 
 LONGDESC
@@ -66,10 +71,13 @@ where
 #### Keyword
 In uppercase if you want to have the log comment appears into the generated ChangeLog file.
 
-The keyword can be ommitted if your commit does not fit in any of the following categories:
+The keyword can be omitted if your commit does not fit in any of the following categories:
+
 - Fix/FIX: for a bug fix
-- New/NEW: for an unreferenced new feature (Opening a feature request and using close is prefered)
 - Close/CLOSE: for closing a referenced feature request
+- New/NEW: for an unreferenced new feature (Opening a feature request and using close is preferred)
+- Perf/PERF: for a performance enhancement
+- Qual/QUAL: for quality code enhancement or re-engineering
 
 #### Issuenum
 If your commit fixes a referenced bug or feature request.
@@ -90,22 +98,24 @@ Feel free to express technical details, use cases or anything relevant to the cu
 
 This section can span multiple lines.
 
-Try to keep lines under 120 characters.
+If your PR is a change on interface, you must also paste a screenshot showing the new screen.
 
 #### Examples
 <pre>
 FIX|Fix #456 Short description (where #456 is number of bug fix, if it exists. In upper case to appear into ChangeLog)
 or
-NEW|New Short description (In upper case to appear into ChangeLog, use this if you add a feature not tracked, otherwise use CLOSE #456)
-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)
+or
 Short description (when the commit is not introducing feature nor closing a bug)
 
-Long description (Can span accross multiple lines).
+Long description (Can span across multiple lines).
 </pre>
 
+
 ### Pull Requests
+
 Pull Request (PR) process is the process to submit a change (enhancement, bug fix, ...) into the code of the project. There is some rules to know and
 a process to follow to optimize the chance to have PRs merged efficiently...
 
@@ -115,11 +125,13 @@ 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.
+
 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 add a 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.
+* 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).
 
@@ -130,7 +142,8 @@ If your PR has errors reported by the Continuous Integration Platform, it means
 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.
 
-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%. 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.
+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%. 
+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.
 
 
 ### Resources
@@ -144,7 +157,7 @@ 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 assume 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.
 

.github/FUNDING.yml

@@ -2,4 +2,4 @@
 
 open_collective: dolibarr
 custom: https://wiki.dolibarr.org/index.php/Subscribe
-github: [eldy]
+github: [eldy]

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -7,7 +7,7 @@ body:
     attributes:
       value: |
         This is a template to help you report good issues. You may use [Github Markdown](https://help.github.com/articles/getting-started-with-writing-and-formatting-on-github/) syntax to format your issue report.
-        
+
   - type: textarea
     id: bug
     attributes:
@@ -19,53 +19,30 @@ body:
   - type: input
     id: environment-version
     attributes:
-      label: Environment Version
+      label: Dolibarr Version
       description: Affected Dolibarr version(s)
+      placeholder: 19.0, develop, ...
 
-  - type: input
-    id: environment-os
-    attributes:
-      label: Environment OS
-      description: Server OS type and version
-
-  - type: input
-    id: environment-webserver
-    attributes:
-      label: Environment Web server
-      description: Webserver type and version
-
   - type: input
     id: environment-php
     attributes:
       label: Environment PHP
       description: PHP version
-      
+
   - type: input
     id: environment-database
     attributes:
       label: Environment Database
       description: Database type and version
 
-  - type: input
-    id: environment-urls
-    attributes:
-      label: Environment URL(s)
-      description: Affected URL(s)
-
-  - type: textarea
-    id: expected-behaviour
-    attributes:
-      label: Expected and actual behavior
-      description: Verbose description
-
   - type: textarea
     id: reproduce
     attributes:
-      label: Steps to reproduce the behavior
+      label: Steps to reproduce the behavior and expected behavior
       description: Verbose description
-      
+
   - type: textarea
     id: files
     attributes:
       label: Attached files
-      description: Screenshots, screencasts, dolibarr.log, debugging informations
+      description: Screenshots, screencasts, dolibarr.log, debugging information

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -21,7 +21,7 @@ body:
     attributes:
       label: Use case
       description: Verbose description
-      
+
   - type: textarea
     id: suggested-implementation
     attributes:

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,7 +1,7 @@
 # Instructions
 *This is a template to help you make good pull requests. You may use [Github Markdown](https://help.github.com/articles/getting-started-with-writing-and-formatting-on-github/) syntax to format your issue report.*
 *Please:*
-- *only keep the "FIX", "CLOSE" or "NEW" section* (use uppercase to have the PR appears into the ChangeLog, lowercase will not appears)
+- *only keep the "FIX", "CLOSE", "NEW", "PERF" or "QUAL" section* (use uppercase to have the PR appears into the ChangeLog, lowercase will not appears)
 - *follow the project [contributing guidelines](/.github/CONTRIBUTING.md)*
 - *replace the bracket enclosed texts with meaningful information*
 
@@ -16,3 +16,12 @@
 
 # NEW|New [*Short description*]
 [*Long description*]
+
+
+# PERF|Perf #[*issue_number Short description*]
+[*Long description*]
+
+
+# QUAL|Qual #[*issue_number Short description*]
+[*Long description*]
+

.github/workflows/README.md

@@ -0,0 +1,16 @@
+# Workflow run order
+
+To reduce run minutes, the following order is put in place:
+
+On PR & Merge, always run:
+
+- pre-commit;
+- phan.
+
+When both succeed, start:
+
+- phpstan;
+- Windows-ci;
+- travis.
+
+See https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#running-a-workflow-based-on-the-conclusion-of-another-workflow

.github/workflows/cache-clean-pr.yml

@@ -0,0 +1,36 @@
+---
+name: Cleanup caches of a closed branch
+# See /~https://github.com/actions/cache/blob/main/tips-and-workarounds.md#force-deletion-of-caches-overriding-default-cache-eviction-policy
+on:
+  pull_request:
+    types: [closed]
+  workflow_dispatch:
+jobs:
+  cleanup:
+    runs-on: ubuntu-latest
+    permissions:
+      # `actions:write` permission is required to delete caches
+      #   See also: https://docs.github.com/en/rest/actions/cache?apiVersion=2022-11-28#delete-a-github-actions-cache-for-a-repository-using-a-cache-id
+      actions: write
+      contents: read
+    steps:
+      - name: Check out code
+        uses: actions/checkout@v4
+      - name: Cleanup
+        run: |
+          gh extension install actions/gh-actions-cache
+          REPO=${{ github.repository }}
+          BRANCH=refs/pull/${{ github.event.pull_request.number }}/merge
+          echo "Fetching list of cache key"
+          cacheKeysForPR=$(gh actions-cache list -R $REPO -B $BRANCH | cut -f 1 )
+
+          ## Setting this to not fail the workflow while deleting cache keys. 
+          set +e
+          echo "Deleting caches..."
+          for cacheKey in $cacheKeysForPR
+          do
+              gh actions-cache delete $cacheKey -R $REPO -B $BRANCH --confirm
+          done
+          echo "Done"
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/ci.yml

@@ -0,0 +1,40 @@
+name: "CI"
+
+on: [push, pull_request]
+jobs:
+  pre-commit:
+    uses: ./.github/workflows/pre-commit.yml
+    secrets: inherit
+    with:
+      gh_event: ${{ github.event_name }}
+  phan:
+    uses: ./.github/workflows/phan.yml
+    secrets: inherit
+    with:
+      gh_event: ${{ github.event_name }}
+  phpstan:
+    uses: ./.github/workflows/phpstan.yml
+    secrets: inherit
+    needs: [pre-commit, phan]
+    with:
+      gh_event: ${{ github.event_name }}
+  windows-ci:
+    needs: [pre-commit, phan]
+    secrets: inherit
+    uses: ./.github/workflows/windows-ci.yml
+    with:
+      gh_event: ${{ github.event_name }}
+  gh-travis:  # Runs travis script on github runner (not on travis)
+    if: false
+    # needs: [pre-commit, phan]
+    # needs: [windows-ci]
+    secrets: inherit
+    uses: ./.github/workflows/gh-travis.yml
+    with:
+      gh_event: ${{ github.event_name }}
+
+
+# Note (not tested, from /~https://github.com/orgs/community/discussions/38361)
+# To cancel jobs if one failes, the following action may help
+#       - if: "failure()"
+#        uses: "andymckay/cancel-action@0.3"