Christian Kuhn <lolli@schwarzbu.ch>: Author Summary

Builds triggered by Christian Kuhn <lolli@schwarzbu.ch>

Builds triggered by an author are those builds which contains changes committed by the author.
81
18 (22%)
63 (78%)

Breakages and fixes

Broken means the build has failed but the previous build was successful.
Fixed means that the build was successful but the previous build has failed.
10 (12% of all builds triggered)
5 (6% of all builds triggered)
-5
Build Completed Code commits Tests
CORE › GTN104 › #125 4 days ago
[TASK] Drop reference index in workspace discard more effectively
Dealing with workspace-discard, where rows are always fully
dropped in DB, the expensive reference index operation does
not need to be performed at all. It can be substituted with
straight db-delete calls for affected sys_refindex rows.

Change-Id: Iaa61ef2345c63394fa3286cc9d5dabc5b1a4bb55
Resolves: #92392
Releases: master, 10.4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65852
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
340007 passed
CORE › DAR › #10 5 days ago
[BUGFIX] Properly update reference index when deleting children
When deleting children in a relation, reference index rows
pointing to a child must be updated, otherwise dangling
reference index rows are left, leading to all kinds of trouble.

Change-Id: I8e8086846ae53c5a32aafc553b6ea66d4a17d7fb
Resolves: #67676
Releases: master, 10.4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65809
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
[TASK] Drop reference index in workspace discard more effectively
Dealing with workspace-discard, where rows are always fully
dropped in DB, the expensive reference index operation does
not need to be performed at all. It can be substituted with
straight db-delete calls for affected sys_refindex rows.

Change-Id: Iaa61ef2345c63394fa3286cc9d5dabc5b1a4bb55
Resolves: #92392
Releases: master, 10.4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65841
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
[TASK] Local variable $resolvedIds in PlainDataResolver
Protected class member $resolvedIds is only used
in get(), so it can be turned into a local variable.

Resolves: #92379
Releases: master, 10.4
Change-Id: I889f1c9ac60b990da15f866603c441aecc16472d
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65810
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Georg Ringer <georg.ringer@gmail.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Georg Ringer <georg.ringer@gmail.com>
Reviewed-by: Benni Mack <benni@typo3.org>
[TASK] Drop reference index in workspace discard more effectively
Dealing with workspace-discard, where rows are always fully
dropped in DB, the expensive reference index operation does
not need to be performed at all. It can be substituted with
straight db-delete calls for affected sys_refindex rows.

Change-Id: Iaa61ef2345c63394fa3286cc9d5dabc5b1a4bb55
Resolves: #92392
Releases: master, 10.4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65852
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
[BUGFIX] Properly update reference index when deleting children
When deleting children in a relation, reference index rows
pointing to a child must be updated, otherwise dangling
reference index rows are left, leading to all kinds of trouble.

Change-Id: I8e8086846ae53c5a32aafc553b6ea66d4a17d7fb
Resolves: #67676
Releases: master, 10.4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65827
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
[TASK] Local variable $resolvedIds in PlainDataResolver
Protected class member $resolvedIds is only used
in get(), so it can be turned into a local variable.

Resolves: #92379
Releases: master, 10.4
Change-Id: I889f1c9ac60b990da15f866603c441aecc16472d
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65817
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
Testless build
CORE › GTN › #245 5 days ago
[TASK] Drop reference index in workspace discard more effectively
Dealing with workspace-discard, where rows are always fully
dropped in DB, the expensive reference index operation does
not need to be performed at all. It can be substituted with
straight db-delete calls for affected sys_refindex rows.

Change-Id: Iaa61ef2345c63394fa3286cc9d5dabc5b1a4bb55
Resolves: #92392
Releases: master, 10.4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65841
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
[TASK] Local variable $resolvedIds in PlainDataResolver
Protected class member $resolvedIds is only used
in get(), so it can be turned into a local variable.

Resolves: #92379
Releases: master, 10.4
Change-Id: I889f1c9ac60b990da15f866603c441aecc16472d
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65810
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Georg Ringer <georg.ringer@gmail.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Georg Ringer <georg.ringer@gmail.com>
Reviewed-by: Benni Mack <benni@typo3.org>
[BUGFIX] Properly update reference index when deleting children
When deleting children in a relation, reference index rows
pointing to a child must be updated, otherwise dangling
reference index rows are left, leading to all kinds of trouble.

Change-Id: I8e8086846ae53c5a32aafc553b6ea66d4a17d7fb
Resolves: #67676
Releases: master, 10.4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65809
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
336544 passed
CORE › GTC › #5907 6 days ago
[TASK] Drop reference index in workspace discard more effectively
Dealing with workspace-discard, where rows are always fully
dropped in DB, the expensive reference index operation does
not need to be performed at all. It can be substituted with
straight db-delete calls for affected sys_refindex rows.

Change-Id: Iaa61ef2345c63394fa3286cc9d5dabc5b1a4bb55
Resolves: #92392
Releases: master, 10.4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65841
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
Testless build
CORE › GTC104 › #480 6 days ago
[TASK] Drop reference index in workspace discard more effectively
Dealing with workspace-discard, where rows are always fully
dropped in DB, the expensive reference index operation does
not need to be performed at all. It can be substituted with
straight db-delete calls for affected sys_refindex rows.

Change-Id: Iaa61ef2345c63394fa3286cc9d5dabc5b1a4bb55
Resolves: #92392
Releases: master, 10.4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65852
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
74737 passed
CORE › GTN104 › #124 5 days ago
[BUGFIX] Properly update reference index when deleting children
When deleting children in a relation, reference index rows
pointing to a child must be updated, otherwise dangling
reference index rows are left, leading to all kinds of trouble.

Change-Id: I8e8086846ae53c5a32aafc553b6ea66d4a17d7fb
Resolves: #67676
Releases: master, 10.4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65827
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
[TASK] Local variable $resolvedIds in PlainDataResolver
Protected class member $resolvedIds is only used
in get(), so it can be turned into a local variable.

Resolves: #92379
Releases: master, 10.4
Change-Id: I889f1c9ac60b990da15f866603c441aecc16472d
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65817
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
339949 passed
CORE › GTC104 › #470 6 days ago
[BUGFIX] Properly update reference index when deleting children
When deleting children in a relation, reference index rows
pointing to a child must be updated, otherwise dangling
reference index rows are left, leading to all kinds of trouble.

Change-Id: I8e8086846ae53c5a32aafc553b6ea66d4a17d7fb
Resolves: #67676
Releases: master, 10.4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65827
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
74737 passed
CORE › GTC › #5878 6 days ago
[BUGFIX] Properly update reference index when deleting children
When deleting children in a relation, reference index rows
pointing to a child must be updated, otherwise dangling
reference index rows are left, leading to all kinds of trouble.

Change-Id: I8e8086846ae53c5a32aafc553b6ea66d4a17d7fb
Resolves: #67676
Releases: master, 10.4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65809
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
73697 passed
CORE › GTC › #5846 6 days ago
[TASK] Local variable $resolvedIds in PlainDataResolver
Protected class member $resolvedIds is only used
in get(), so it can be turned into a local variable.

Resolves: #92379
Releases: master, 10.4
Change-Id: I889f1c9ac60b990da15f866603c441aecc16472d
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65810
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Georg Ringer <georg.ringer@gmail.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Georg Ringer <georg.ringer@gmail.com>
Reviewed-by: Benni Mack <benni@typo3.org>
73676 passed
CORE › GTC104 › #458 6 days ago
[TASK] Local variable $resolvedIds in PlainDataResolver
Protected class member $resolvedIds is only used
in get(), so it can be turned into a local variable.

Resolves: #92379
Releases: master, 10.4
Change-Id: I889f1c9ac60b990da15f866603c441aecc16472d
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65817
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
74714 passed
Build Completed Code commits Tests
CORE › GTC › #5907 6 days ago
[TASK] Drop reference index in workspace discard more effectively
Dealing with workspace-discard, where rows are always fully
dropped in DB, the expensive reference index operation does
not need to be performed at all. It can be substituted with
straight db-delete calls for affected sys_refindex rows.

Change-Id: Iaa61ef2345c63394fa3286cc9d5dabc5b1a4bb55
Resolves: #92392
Releases: master, 10.4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65841
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
Testless build
CORE › GTN104 › #119 1 week ago
[BUGFIX] Separate 'delete' and 'discard' in DataHandler
There are 4 "drop record" scenarios in workspaces:
* Delete a new or changed record in list/page module
* Create a delete placeholder in list/page module to mark a
  live record as to-be-deleted on workspace publish
* Discard (throw away) a change in workspace module
* Flush all workspace changes by deleting a sys_workspace
  record.

All these scenarios are handled with the same DataHandler
code which leads to tons of bugs since especially
"delete & create delete placeholder" compared to
"discard & flush" are logically different things.

The patch separates discard and flush to a new codebase.
First patch sets started with a 1:1 copy of the delete code,
then carefully refactored the code to its final state. The
roughly 850 lines of delete code are streamlined to about
300 lines for discard and flush. The code is much easier
to follow, recursions are simplified and access checks are
in one place.

Discard previously created a mixture of hard and soft deleted
records in the database, leading to a huge mess. This changed:
Discard now always means that records are dropped from database.

The discard code now properly cascades down into relations,
solving tons of bugs along the way. The functional DataHandler
tests are refactored and heavily extended to cover discard.
Two previously existing issues are not fixed yet: ManyToMany
relations are not properly cleaned up on discard, and discarding
does not fully follow localization overlays in 'connected' mode.
Those scenarios are marked with @todo's in the .csv files and
should be relatively easy to solve with dedicated single patches.

Change-Id: Ie33dd2bdc333a4d8ed9314b7520212cc11942c89
Resolves: #85778
Resolves: #92336
Releases: master, 10.4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65766
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
3 of 95149 failed
CORE › GTN104 › #108 3 weeks ago
[BUGFIX] Update ref-index when deleting new workspace relations
Adding an image to a workspace content element adds two
sys_refindex entries: One for the sys_file_reference
t3ver_state=-1 and one for the t3ver_state=1 record.

Deleting the image reference again in workspaces only sets
one of the two to deleted in sys_refindex, leading to orphan
sys_refindex entries.

The patch fixes this by adding a 'redo refindex' call at the
appropriate place.

There are more issues when 'discard changes' is used together with
multi-level relations (tt_content->hotel->offer->price): Discard
does not properly cascade in those cases, yet. The patch touches
this as a side-effect and does not improve the situation. The .csv
files are marked with @todo accordingly and will be fixed with further
patches. Those scenarios are more seldom than a broken sys_refindex
for FAL images which is the primary goal of this patch.

Analyzing the test scenarios, the patch actually removes various
rows from sys_refindex where the left part of the relation is set
to deleted. This is correct and wanted: In the end we don't want
sys_refindex to contain reference to deleted rows at all. This
strategy will be further followed with other patches.

Resolves: #61917
Related: #67676
Releases: master, 10.4
Change-Id: I3246f263e393c6b384c2d98b0dbbcf4dbbeeccad
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65628
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
1 of 284858 failed
CORE › GTC › #5352 3 weeks ago
[BUGFIX] Update ref-index when deleting new workspace relations
Adding an image to a workspace content element adds two
sys_refindex entries: One for the sys_file_reference
t3ver_state=-1 and one for the t3ver_state=1 record.

Deleting the image reference again in workspaces only sets
one of the two to deleted in sys_refindex, leading to orphan
sys_refindex entries.

The patch fixes this by adding a 'redo refindex' call at the
appropriate place.

There are more issues when 'discard changes' is used together with
multi-level relations (tt_content->hotel->offer->price): Discard
does not properly cascade in those cases, yet. The patch touches
this as a side-effect and does not improve the situation. The .csv
files are marked with @todo accordingly and will be fixed with further
patches. Those scenarios are more seldom than a broken sys_refindex
for FAL images which is the primary goal of this patch.

Analyzing the test scenarios, the patch actually removes various
rows from sys_refindex where the left part of the relation is set
to deleted. This is correct and wanted: In the end we don't want
sys_refindex to contain reference to deleted rows at all. This
strategy will be further followed with other patches.

Resolves: #61917
Related: #67676
Releases: master, 10.4
Change-Id: I3246f263e393c6b384c2d98b0dbbcf4dbbeeccad
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65510
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
585 of 73700 failed
CORE › GTC104 › #356 3 weeks ago
[BUGFIX] PlainDataResolver misses DeletedRestriction
The PlainDataResolver is used to find overlay id's of live
id's in workspace context. One usage is the ReferenceIndex.

In scenarios 'modify content, discard content, modify again'
with relations, the PlainDataResolver sometimes fetches rows
that have been set to deleted (discarded) already together
with the rows that should be fetched. Depending on the order
of the result rows - which depends on the DBMS - wrong overlay
rows are calculated sometimes.

The patch adds a database DeletedRestriction at 3 of 4 places
in the PlainDataResolver to only fetch correct rows. The last
place triggers another side-effect that needs to be tackled
with another patch and is commented as @todo for now.

The tests add missing sys_refindex rows to the 6 tests that
failed on postgres before. Additionally, for some other
IRRE/CSV workspace tests, the sys_refindex changes slightly
and is more correct now.

Resolves: #92190
Releases: master, 10.4
Change-Id: I14f5211b5996d7f53738b9e086c3866aa1a4eaeb
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65599
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
1 of 74675 failed
CORE › GTC › #5331 3 weeks ago
[BUGFIX] PlainDataResolver misses DeletedRestriction
The PlainDataResolver is used to find overlay id's of live
id's in workspace context. One usage is the ReferenceIndex.

In scenarios 'modify content, discard content, modify again'
with relations, the PlainDataResolver sometimes fetches rows
that have been set to deleted (discarded) already together
with the rows that should be fetched. Depending on the order
of the result rows - which depends on the DBMS - wrong overlay
rows are calculated sometimes.

The patch adds a database DeletedRestriction at 3 of 4 places
in the PlainDataResolver to only fetch correct rows. The last
place triggers another side-effect that needs to be tackled
with another patch and is commented as @todo for now.

The tests add missing sys_refindex rows to the 6 tests that
failed on postgres before. Additionally, for some other
IRRE/CSV workspace tests, the sys_refindex changes slightly
and is more correct now.

Resolves: #92190
Releases: master, 10.4
Change-Id: I14f5211b5996d7f53738b9e086c3866aa1a4eaeb
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65617
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
120 of 73712 failed
CORE › GTC95 › #774 3 weeks ago
[TASK] CSV integrity test script can fix fixtures
CSV fixture files are a straight way to feed test database
with stuff and to assert database state after operations.
Script Build/Scripts/checkIntegrityCsvFixtures.php tests those
files for integrity, making sure all lines have the same number
of columns. Maintaining the number of commas when fiddling with
functional tests however is annoying.

The patch adds options to checkIntegrityCsvFixtures.php:
* '--fix' simply fixes files with broken integrity
* '--fixAll' goes through all files and looks for details
  like superfluous comma.

While --fixAll is used once now to establish a good baseline
on all .csv fixtutre files, --fix can be used whenever the
integrity script mumbles about broken stuff:

Build/Scripts/checkIntegrityCsvFixtures.php --fix

It is also added to runTests.sh:

Build/Scripts/runTests.sh -s fixCsvFixtures

Change-Id: Idee2a97094f56d059b02f801ffecb50a7ce21a5c
Resolves: #92207
Releases: master, 10.4, 9.5
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65589
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
6 of 75760 failed
CORE › GTC › #5262 3 weeks ago
[!!!][TASK] Refactor create bookmark handling
The backend shortcut / bookmark handlig API was designed to
hand over relevant get/post arguments as key only (eg. 'id').
The underlying code then pulled values from GET/POST or from
SOBE->MOD_SETTINGS. This is ugly, there shouldn't be such
magic: Only controllers know relevant keys and values, so
it should hand them over directly to the shortcut API.

The patch changes this:
* Old and unused ViewHelper f:be.buttons.shortcut is deprecated.
* ViewHelper be:moduleLayout.button.shortcutButton deprecates
  argument 'getVars' and adds new argument 'arguments'.
* Class ShortcutButton has a new setter 'setArguments' that
  accepts all relevant argument key/value pairs to create a
  shortcut. Existing get/set related methods are deprecated.
* Helper methods 'makeShortcutIcon' and 'makeShortcutUrl' of
  class ModuleTemplate are deprecated and implemented in class
  ShortcutButton directly.
* All core usages are adapted to new API.
* Shortcut handling was the last core usage of SOBE, so last
  $GLOBALS['SOBE'] = $this assignments can be finally removed.

Impact:
* Shortcuts to modules not directly reachable via main menu
  do not work due to limits of the module registration API. An
  example is the 'create multiple pages' controller. This issue
  exists before the patch, affected controllers no longer render
  a shortcut button for now.
* The old code usually added the 'route' argument twice for shortcuts.
  This has been resolved. As a side effect, the comparison if a
  shortcuts exists (yellow shortcut icon) fails currently for existing
  shortcuts when the patch is applied: The comparison relies on
  direct string equality since shortcuts always store the final url in
  the database. This storage strategy should be changed with another
  patch that will solve the 'no yellow icon' issue at the same time.

Change-Id: I3ccd2b8f6adab8e7780c5f9911fdea013ccfa99b
Resolves: #92132
Releases: master
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65503
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
72875 passed
CORE › GTN › #220 3 weeks ago
[TASK] Default workspaces_perms=0 for new be_users
Field workspace_perms=1 for backend users or groups enables
editing of the live workspace.
When ext:workspaces is loaded, we can assume the extension
is actively used in the instance. If so, many backend users
most likely should NOT have live edit access and the flag
is probably given to only a small group of editors by assigning
a 'chief editor' group or similar that carries the flag.
The patch sets workspace_perms for new backend users by
default to 0 when ext:workspaces is loaded, making it more
unlikely admins accidentially give live edit access to users.

Resolves: #92134
Releases: master, 10.4
Change-Id: Id69a60c732e3dc9a55d8dd861ca1a89792f49af1
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65506
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Jörg Bösche <typo3@joergboesche.de>
Reviewed-by: Benni Mack <benni@typo3.org>
9 of 93976 failed
CORE › GTC104 › #295 4 weeks ago
[BUGFIX] Workspace delete placeholder handling in list module
When a record that exists in live is deleted in a workspace, a
new 'delete placeholder' record is created in the workspace. This
record is used to mark the live workspace record as 'to be deleted'
when the workspace is published.

Those delete placeholder are not shown in the page tree and not
in the page module. The page / element is simply gone. Only the
list module renders those records.

This is confusing usability wise: A user clicks on 'delete' in
list module, reloads the module, and the record is back again.

Additionally, there is an even more confusing mechanism: The 'waste'
icon is substituted by a different icon called 'restore'. 'restore'
however does not actually restore changes that may have been done
to the record in the workspace before, instead it simply sets the
delete placeholder record to deleted, which makes the underlying
live record 'shine through' in the workspace again.

Interacting with delete placeholder records is also useless,
for instance edited content of delete placeholder records is
always gone in the end. So most action icons don't make sense.

Looking at the lifecycle of workspace records, there are only
two final results: A change is either discarded, or is published
to live. This is managed exclusively in the workspace module.
Having the third option 'restore' in the list module - that is
basically the same as discarding a delete placeholder in workspace
module - is very confusing.

The best option would be to not render delete placeholder rows
in the list module at all. Unfortunately this can't be done due
to the workspace overlay mechanics: Especially the count and
limit / pagination handling in list module is done on db level before
the module knows that certain rows shouldn't be rendered. We need to
have some serious refactoring before this can be solved.

For now, the solution is to still render delete placeholder records
in list module, to 'strike through' their title (similar to workspace
module) and to disable all control icons and the click menu on them.
This way the final fate of a delete placeholder can be decided only
in the workspace module - just like all other workspace records.

Change-Id: Id8a95c41f2bbe90ea68f40e376a4d36d3a2019b8
Resolves: #90679
Resolves: #52700
Releases: master, 10.4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65495
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Daniel Windloff
Tested-by: Riccardo De Contardi <erredeco@gmail.com>
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Daniel Windloff
Reviewed-by: Björn Jacob <bjoern.jacob@tritum.de>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65498
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
1 of 74552 failed
Build Completed Code commits Tests
CORE › GTC › #5846 6 days ago
[TASK] Local variable $resolvedIds in PlainDataResolver
Protected class member $resolvedIds is only used
in get(), so it can be turned into a local variable.

Resolves: #92379
Releases: master, 10.4
Change-Id: I889f1c9ac60b990da15f866603c441aecc16472d
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65810
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Georg Ringer <georg.ringer@gmail.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Georg Ringer <georg.ringer@gmail.com>
Reviewed-by: Benni Mack <benni@typo3.org>
73676 passed
CORE › GTN104 › #120 1 week ago
[BUGFIX] Skip sys_refindex for workspace placeholders
The reference index can be seen as a cache for relations.
It is used in various places to show how many other records
have a relation to a given record, for instance in list
and filelist module and in the record info modal.

In workspaces, new and moved records create records pairs:
t3ver_state -1 & 1 and t3ver_state 3 & 4. The backend
always shows only one of these pairs. The reference index
creates an entry for each record, so two for each pair.
This is useless and confusing for editors: If for instance
a new file reference is added to a content element in
workspaces, the file list shows two usages of the file
instead of only one.

The patch suppresses reference index entries for the
placeholder records - t3ver_state 1 and 3 - so each pair
ends up with only one sys_refindex entry.

Resolves: #92345
Related: #61917
Releases: master, 10.4
Change-Id: I16ede3a9f1b66a7195526a224e9f1c43c03d7ba6
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65782
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
[BUGFIX] Stop calling a non-static method statically
Resolves: #92344
Releases: master, 10.4
Change-Id: Ia34b93a6fefaee408da7b54965cf02e138cadf26
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65781
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
339773 passed
CORE › GTC › #5747 1 week ago
[BUGFIX] Skip sys_refindex for workspace placeholders
The reference index can be seen as a cache for relations.
It is used in various places to show how many other records
have a relation to a given record, for instance in list
and filelist module and in the record info modal.

In workspaces, new and moved records create records pairs:
t3ver_state -1 & 1 and t3ver_state 3 & 4. The backend
always shows only one of these pairs. The reference index
creates an entry for each record, so two for each pair.
This is useless and confusing for editors: If for instance
a new file reference is added to a content element in
workspaces, the file list shows two usages of the file
instead of only one.

The patch suppresses reference index entries for the
placeholder records - t3ver_state 1 and 3 - so each pair
ends up with only one sys_refindex entry.

Resolves: #92345
Related: #61917
Releases: master, 10.4
Change-Id: I16ede3a9f1b66a7195526a224e9f1c43c03d7ba6
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65767
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
73658 passed
CORE › GTC › #5104 4 weeks ago
[TASK] Default workspaces_perms=0 for new be_users
Field workspace_perms=1 for backend users or groups enables
editing of the live workspace.
When ext:workspaces is loaded, we can assume the extension
is actively used in the instance. If so, many backend users
most likely should NOT have live edit access and the flag
is probably given to only a small group of editors by assigning
a 'chief editor' group or similar that carries the flag.
The patch sets workspace_perms for new backend users by
default to 0 when ext:workspaces is loaded, making it more
unlikely admins accidentially give live edit access to users.

Resolves: #92134
Releases: master, 10.4
Change-Id: Id69a60c732e3dc9a55d8dd861ca1a89792f49af1
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65506
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Jörg Bösche <typo3@joergboesche.de>
Reviewed-by: Benni Mack <benni@typo3.org>
73164 passed
You have insufficient permissions to see all of the builds.