| Q | A
|-----------------|-----
| Branch? | 1.14 <!-- see the comment below -->
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| License | MIT
<!--
- Bug fixes must be submitted against the 1.14 or 2.1 branch
- Features and deprecations must be submitted against the 2.2 branch
- Make sure that the correct base branch is set
To be sure you are not breaking any Backward Compatibilities, check the
documentation:
https://docs.sylius.com/en/latest/book/organization/backward-compatibility-promise.html
-->
For details, this PR follows the design described in the RFC:
https://github.com/Sylius/Sylius/issues/18588
This is connected with https://github.com/Sylius/Sylius/pull/18574
| Q | A
|-----------------|-----
| Branch? | 1.14
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | https://github.com/Sylius/Sylius/issues/16120
| License | MIT
The \Sylius\Bundle\ReviewBundle\EventListener\ReviewChangeListener
(registered as Doctrine event listener) already handles rating
recalculation for all review changes (postPersist, postUpdate,
preRemove), making the
state machine callback redundant.
Solution
Disable the sylius_update_rating callback by adding disabled: true
instead of removing it entirely.
Why disabled: true instead of removal?
1. No BC break - the updateFromReview() method called by this callback
remains intact, preserving the ReviewableRatingUpdaterInterface and
service definitions
2. Flexibility - users who rely on this callback (e.g., for custom
priority ordering with their own callbacks) can re-enable it in their
configuration with disabled: false
3. Transparency - the callback definition remains visible in
configuration, documenting what was disabled and why, which helps with
debugging and understanding the system's
history
| Q | A
|-----------------|-----
| Branch? | 1.14
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Related tickets | https://github.com/Sylius/Sylius/issues/17568
| License | MIT
When finalizing an order, while checking whether products and variants
are "isEnabled," a check has also been added to see if they are assigned
to the current channel.
| Q | A
|-----------------|-----
| Branch? | 1.14
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | #18549
| License | MIT
Details in file AUDIT-IGNORE.md
| Q | A
|-----------------|-----
| Branch? | 1.14
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets |
| License | MIT
Fix build CI through added a few cve to ignore section in file
composer.json.
1. PKSA-yhcn-xrg3-68b1 (Twig - CVE-2024-45411)
Sandbox bypass - Attackers can execute dangerous code in Twig templates
by bypassing sandbox security restrictions.
- Fixed in: Twig 1.44.8, 2.16.1, 3.14.0
2. PKSA-2wrf-1xmk-1pky (Twig - CVE-2024-51755)
Access to protected data - Using the ?? operator and array access allows
reading private data without security policy checks.
- Fixed in: Twig 3.11.2, 3.14.1
3. PKSA-gs8r-6kz6-pp56 (likely API Platform)
GraphQL data exposure - Improper caching in GraphQL allows access to
other users' data or bypassing operation security.
- Related to API Platform GraphQL security issues
- Fixed in: API Platform 3.4.17, 4.0.22
4. PKSA-gnn4-pxdg-q76m (likely API Platform or Twig)
Exception details disclosure - Error messages may contain sensitive
system information visible in JSON responses.
- Related to API Platform error handling
- Fixed in: API Platform 3.2.5+
Details:
https://www.cvedetails.com/vulnerability-list/vendor_id-19033/product_id-48690/Symfony-Twig.htmlhttps://api-platform.com/docs/extra/security/
| Q | A |
|-----------------|--------------------------------------------------------------|
| Branch? | 1.14 |
| Bug fix? | yes |
| New feature? | no |
| BC breaks? | no |
| Deprecations? | no |
| Related tickets | https://github.com/doctrine/orm/issues/12245 |
| License | MIT |
## Summary
Doctrine ORM versions 2.20.7 and 3.5.3 contain a regression that breaks
queries with empty arrays, causing SQL syntax errors like `WHERE t0.id
IN ()`.
This PR adds these versions to the `conflict` section of composer.json
to prevent them from being installed until the upstream issue is fixed.
| Q | A
|-----------------|-----
| Branch? | 1.14
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | #18459 (it introduced step-based chrome run)
| License | MIT
## Description
This PR resolves the "user data directory is already in use" error that
causes all Panther tests to fail on Symfony 5.4 matrix jobs after
upgrading to BuildTestAppAction v3.0.1.
The issue occurs because BuildTestAppAction v3.0.1 starts a background
Chrome process (for Chromedriver on port 9222) without specifying a
user-data-dir, which conflicts with Panther's Chrome instance attempting
to use the same default directory.
## Root Cause
The Sylius behat.yml.dist configuration was incorrectly placing Chrome
arguments under `options.browser_arguments`, which is **completely
ignored** by the behat-panther-extension. The correct configuration path
is `manager_options.capabilities.goog:chromeOptions.args`.
This configuration error was introduced in commit 04a222ba67 and went
unnoticed because it only manifested when BuildTestAppAction v3.0.1
removed the default Chrome installation (which was already running with
a user-data-dir).
## Changes
- **behat.yml.dist**: Fixed Chrome arguments configuration to use the
correct path:
- Moved arguments from
`sessions.panther.panther.options.browser_arguments` (ignored)
- To
`sessions.panther.panther.manager_options.capabilities.goog:chromeOptions.args`
(correct)
- Added `--user-data-dir=/tmp/panther-chrome-data` to prevent conflicts
with Chromedriver's Chrome instance
This ensures Panther's Chrome process uses a unique user data directory,
allowing it to run alongside BuildTestAppAction's Chrome instance
without conflicts.
## Technical Details
- BuildTestAppAction's Chrome uses default user-data-dir (or will use
`/tmp/chrome-chromedriver-behat` in future versions)
- Panther's Chrome now explicitly uses `/tmp/panther-chrome-data`
- The fix resolves the issue on both Symfony 5.4 (Panther v2.1.1) and
Symfony 6.4 (Panther v2.2.0)
| Q | A
|-----------------|-----
| Branch? | 1.14
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | fixes#11793
| License | MIT
<!--
- Bug fixes must be submitted against the 1.14 or 2.0 branch
- Features and deprecations must be submitted against the 2.1 branch
- Make sure that the correct base branch is set
To be sure you are not breaking any Backward Compatibilities, check the
documentation:
https://docs.sylius.com/en/latest/book/organization/backward-compatibility-promise.html
-->
| Q | A
|-----------------|-----
| Branch? | 1.14
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | fixes https://github.com/Sylius/Sylius/issues/18397
| License | MIT
| Q | A
|-----------------|-----
| Branch? | 1.14
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | https://github.com/Sylius/Sylius/issues/12738
| License | MIT
| Q | A
|-----------------|-----
| Branch? | 1.14
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | https://github.com/Sylius/Sylius/issues/14879
| License | MIT
Issue was present in 1.14. Updated files from old array-based
translations schema to the proper object-based schema with additional
properties support.
<!--
- Bug fixes must be submitted against the 1.14 or 2.0 branch
- Features and deprecations must be submitted against the 2.1 branch
- Make sure that the correct base branch is set
To be sure you are not breaking any Backward Compatibilities, check the
documentation:
https://docs.sylius.com/en/latest/book/organization/backward-compatibility-promise.html
-->
| Q | A
|-----------------|-----
| Branch? | 1.14
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | fixes#16771
| License | MIT
<!--
- Bug fixes must be submitted against the 1.14 or 2.0 branch
- Features and deprecations must be submitted against the 2.1 branch
- Make sure that the correct base branch is set
To be sure you are not breaking any Backward Compatibilities, check the
documentation:
https://docs.sylius.com/en/latest/book/organization/backward-compatibility-promise.html
-->
| Q | A
|-----------------|-----
| Branch? | 1.14
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Related tickets | https://github.com/Sylius/Sylius/issues/16151
| License | MIT
- Removed validation group from route file;
- Added validation group to parameters.
