Bug #59224: Changing the order of gridelements backend layouts destroys them - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #59224

closed

Changing the order of gridelements backend layouts destroys them

Added by Jens Jacobsen over 10 years ago. Updated about 6 years ago.

Status:

Closed

Priority:

Must have

Assignee:

Category:

Target version:

Start date:

2014-05-30

Due date:

% Done:

100%

Estimated time:

TYPO3 Version:

6.2

PHP Version:

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

Changing the sorting for the gridelement backend alyouts using the list view in TYPO3 6.2.3 destroys something. I had about seven elements and after sorting them, the page which used some of them was totally messed up. Also the list of available grids was not showing some of them anymore.

I noticed that the alias field of the database entries gets filled when using the sorting in the list view. I cleared out all alias fields like they where before after adding a fresh object to the table via the backend, and availability changed back to normal.

Files

Download all files

01_Before_Moving.png (123 KB) 01_Before_Moving.png	Before moving the objects	Jens Jacobsen, 2014-05-30 10:24
02_New_Sorted.png (101 KB) 02_New_Sorted.png	New sorting	Jens Jacobsen, 2014-05-30 10:24
03_Add_after_sorting.png (111 KB) 03_Add_after_sorting.png	Want to add new gridelement	Jens Jacobsen, 2014-05-30 10:24
04_Values_In_Alias_Field.png (48.7 KB) 04_Values_In_Alias_Field.png	Alias field filled	Jens Jacobsen, 2014-05-30 10:24

Actions

Copy link

Updated by Jo Hasenau over 10 years ago

Project changed from 1933 to 2513
Status changed from New to Accepted
Assignee set to Jo Hasenau

Can reproduce that bug, but have to check, if this a core or GE problem.

Actions

Copy link

Updated by Jo Hasenau over 10 years ago

Project changed from 2513 to TYPO3 Core

It seems that this behaviour is caused by

\TYPO3\CMS\Core\DataHandling\DataHandler::fixUniqueInPid

The field "alias" is set to evalulate as "uniqueInPid", but instead of taking care of actual values only, the method creates a new value for empty values as well.
This leads to values being assigned to both, the record which gets moved and the one it is moved "after".
So moving will create up to 2 new values for aliases, that have been empty before.

Actions

Copy link

Updated by Markus Klein over 10 years ago

Assignee deleted (~~Jo Hasenau~~)
Is Regression set to No

What is the alias field good for?
how can it be uniqueInPid when there are multiple empty fields.

Actions

Copy link

Updated by Jo Hasenau over 9 years ago

Values have to be unique in PID or not set at all.
So "empty" is not a value and therefor does not have to be unique.

Actions

Copy link

Updated by Markus Klein over 9 years ago

I can confirm that this method really lacks a check for an empty value.

But on the other hand I don't understand why this didn't cause more troubles, since this method is called from moveRecord_raw().
It means that many pages should have an alias now.

Actions

Copy link

Updated by Markus Klein over 9 years ago

Clear now for me. That code is never called for pages.

And uniqueInPid is only used for fe_user in Core, but username may never be empty ;-)

Actions

Copy link

Updated by Gerrit Code Review over 9 years ago

Status changed from Accepted to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/38413

Actions

Copy link

Updated by Gerrit Code Review over 9 years ago

Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/38421

Actions

Copy link