Merged https://github.com/steffjenl/okazanta to 2.5 branch, mean reasen is to get security patches and PHP 8.1 support

• Upgrade to Laravel 8.x
• Upgrade PHP to 7.3 till 8.1 support
• RSS Support
• ICAL Attachment on Schedule notification
• Dutch lang files updated
• New Laravel Notification templates (Copyright and title are now the site name)
• Every notification are using now the queue
• SQL Injection protection for API
• CORS protection standard enabled

TO DO:

• Twitter, Badger, Emoij packages must first released and changed in composer.json

I will look at it in the end off october. For the Larvavel 6.x to Larvel 8.x upgrade you must change a lot files at once to get the tests green and all the functionality working. For now I will close the PR @jbrooksuk

TL;DR

Adds dev tooling to cachet/core

Description

This PR adds the following dev tools into the cachet/core project

• PHPStan (via Larastan), set to Level 5 – this can be incremented gradually if we want a higher level of strictness
• PHPInsights – configured to the "laravel" preset with "phpstorm" set as the IDE
• Laravel Pint – default preset, could be changed / adjusted as required

Important things to note

• I've updated all PHP files to use declare(strict_types=1);
• I've added format (pint), analyse (phpstan) and complexity scripts to the composer.json
• I've not added any checks into CI (yet)

Thanks for this, @joelbutcher. However, I'm not going to merge this at this time. I really want to nail the features and design implementation before we get into any of this.

Note that Pint runs automatically when anything is merged into main.

Let's keep PHPStan in mind for the future though.

This PR simplifies the registration of API routes, by combining related registration declarations into a single apiResource declaration.

Most resources can be bundled together via Route::apiResources([...]). However, the scoped resources incidents.updates and metrics.points have to be registered as separate Route::apiResource(...) to accommodate correctly scoping resources to their parents as well as defining the route param names used by Laravel's implicit route binding (thus removing the requirement to alter the variable names type hinted in the controllers... e.g. renaming $incidentUpdate to just $update)

This PR adds the following dev tools into the cachet/core project:

• PHPStan (via Larastan), set to Level 5 – this can be incremented gradually if we want a higher level of strictness
• PHPInsights – configured to the "laravel" preset with "phpstorm" set as the IDE
• Laravel Pint – default preset, could be changed / adjusted as required

Important things to note

• I've updated all PHP files to use declare(strict_types=1);
• I've added format (pint), analyse (phpstan) and complexity scripts to the composer.json
• I've not added any checks into CI (yet)

Good morning,

I am currently evaluating the Cachet 2.4 solution to display the status of an information system. I encounter a bug in the dashboard display: When the dashboard has not been accessed for several hours, there is systematically a delay of 2 minutes before it can be displayed. I don't see any errors in the docker logs, I don't understand why this is happening.

The login form is displayed quickly if necessary and it is only after validation of the login that the "blocking" is felt. Once these few minutes have passed, I regain full access to the dashboard.

This is all the more bizarre as the public HMI continues to work perfectly during this period of time.

Here is my configuration:

Docker compose -postgres:12 -redis:latest -postfix (custom container) -stamp:2.4 (custom container) environment: - DB_DRIVER=pgsql - DB_HOST=<postgres_container> - DB_PORT=5432 - DB_DATABASE=<DATABASE> - DB_USERNAME=<DB_USER> - DB_PASSWORD=<DB_PASSWORD> - DB_PREFIX=chq_ - APP_KEY=base64:<MyKey> - APP_LOG=errorlog - APP_ENV=${APP_ENV:-production} - APP_DEBUG=false - DEBUG=false - SESSION_DIVER=redis - CACHE_DRIVER=redis - REDIS_HOST=<redis_container> - MAIL_DRIVER=smtp - MAIL_HOST=<postfix_container> - MAIL_PORT=25 - MAIL_ENCRYPTION=false - PHP_MAX_CHILDREN=20 depends_on: - <postgres_container> - <redis_container> - <postfix_container>

Thanks for your help

This PR simplifies the registration of API routes, by combining related registration declarations into a single apiResource declaration.

Most resources can be bundled together in the apiResources Route builder method.

Scoped resources for incidents.updates and metrics.points have to be registered as separate api resources to accommodate correctly scoping the resource to it's parent as well as defining the route param names used by Laravel's implicit route binding, removing the requirement to alter the variable names type hinted in the controllers (e.g. renaming $incidentUpdate to just $update)

@jbrooksuk What would you want to be able to achieve in that scenario? Is it hiding the database table structure by using different parameter names in the request validation versus column names in the database?

Yeah, basically. It's more for a nicer API than what the DB was giving. We could rename the columns if it came to it.

This raises the discussion around the appropriateness of PUT versus PATCH requests for the API... @jbrooksuk correct me if I'm wrong, but a PUT request should send all attributes, even if they've not changed and PATCH only sends the ones we want to update?

You're right. We've only ever support PUT endpoints though. We could support PATCH too, I guess. Though it does add another endpoint to support.

     * Create a new data object from a JSON string.