Bug #25805: Adding a new task with additional fields saves the wrong values in the additional fields - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #25805

closed

Adding a new task with additional fields saves the wrong values in the additional fields

Added by Michael Franzkowiak over 13 years ago. Updated about 7 years ago.

Status:

Closed

Priority:

Should have

Assignee:

Michael Oehlhof

Category:

scheduler

Target version:

7 LTS

Start date:

2011-04-06

Due date:

% Done:

100%

Estimated time:

TYPO3 Version:

4.5

PHP Version:

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

If you have some task in the sheduler and you add a new task which has some additional fields which are name in the same wording as a field in an already existing task, this field is part of the form section but not visible.
If this existing additional field comes in the form part after the visible field, the value of the unvisible field will be take instead of the value of the visibile field.
It's the same if the field is an input field or a select box.
The problem is, if you don't edit the task again, you have no info about the wrong field setting. Only if you re-edit the task, correct the values and save again, the correct values will be stored.
You can check this, if you place 2 different tasks with the same naming of the additional fields. The first task will be saved correct. The 2nd task has in the Post-vars the values of the 1st task.
You can fix this if you change the section
display additional fields in typo3/sysext/scheduler/mod1/index.php

from


// Add each field to the display, if there are indeed any
if (isset($fields) && is_array($fields)) {
    foreach ($fields as $fieldID => $fieldInfo) {
        $table[$tr][] = t3lib_BEfunc::cshItem($fieldInfo['cshKey'], $fieldInfo['cshLabel'], $this->backPath, '|', false, 'margin-bottom:0px;');
        $table[$tr][] = '<label for="' . $fieldID . '">' . $GLOBALS['LANG']->sL($fieldInfo['label']) . '</label>';
        $table[$tr][] = $fieldInfo['code'];
        $tableLayout[$tr] = array (
            'tr'     => array('<tr id="' . $fieldID . '_row"' . $additionalFieldsStyle .' class="extraFields extra_fields_' . $class . '">', '</tr>'),
            'defCol' => $defaultCell
        );
        $tr++;
    }
}


// Add each field to the display, if there are indeed any
if (isset($fields) && is_array($fields)) {
    foreach ($fields as $fieldID => $fieldInfo) {
        if ($class == $taskInfo['class']) {
            $table[$tr][] = t3lib_BEfunc::cshItem($fieldInfo['cshKey'], $fieldInfo['cshLabel'], $this->backPath, '|', false, 'margin-bottom:0px;');
            $table[$tr][] = '<label for="' . $fieldID . '">' . $GLOBALS['LANG']->sL($fieldInfo['label']) . '</label>';
            $table[$tr][] = $fieldInfo['code'];
            $tableLayout[$tr] = array (
                'tr'     => array('<tr id="' . $fieldID . '_row"' . $additionalFieldsStyle .' class="extraFields extra_fields_' . $class . '">', '</tr>'),
                'defCol' => $defaultCell
            );
            $tr++;
        }
    }
}

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by Markus Klein over 13 years ago

Can you please provide a patch or even better, submit a changeset to gerrit?

Actions

Copy link

Updated by Michael Franzkowiak over 13 years ago

Hi Markus,
it's my first bug report, so i'm no so experienced in your proceeding.

What do you mean with a changeset and how should i submit this?

Actions

Copy link

Updated by Francois Suter over 13 years ago

Hi,

it's my first bug report, so i'm no so experienced in your proceeding.

What do you mean with a changeset and how should i submit this?

The best way to get started is to read this section of typo3.org: http://typo3.org/development/bug-fixing/

However in this case the solution you propose is not correct. It will help in the case of editing a task, but it will fail when adding a new task, because we need all the additional fields in this case (they get shown/hidden via JavaScript).

This problem is known and there's no simple solution. Because it's up to each extension developer to name its own fields, unique name fields cannot be enforced. The Scheduler's manual clearly states that developers should pay attention to this. The problem is that it's very hard to enforce this unicity unless the whole Scheduler API for additional fields is changed. Even TCEforms does not do this: it provides developers with a proper name for their form fields, but developers can choose to ignore it.

Actions

Copy link

Updated by Michael Franzkowiak over 13 years ago

Hi Francois,

Thanks for your reply and your manual tip.

Concerning you answer i made another experience and it works.
In the case of add a new task:
If i ignore the additional fields from the other task, marked with display hidden, the typed in values will be stored exactly in the way the value is filled in the form.

In the case of editing an existing task:
If i edit the task, all defined values are available again as aspected.
And i did this with 10 different tasks and every task works fine and without any problems.

Even if the other additional fields have the style display:hidden, they are available, but not visible, in the form.
And the last field, hidden and possibly from another task, with the same formfield name as the formfield from the displayed task, overwrites my value.
You can reedit the task immediatly after saving the first time, retype the correct value and save again.
Only after saving it twice the correct value will be stored.
But that's not usable if you have a couple of people from the customer who should manage the tasks and you should explain them to save a new task twice until it has the correct value stored.

So i did the workaround in this core extension, well knowing that my correcting will be overwritten by a next update of a newer typo3 release, and that i have to make a backup before.

But as i said, it works very well.

Actions

Copy link

Updated by Christian Kuhn over 12 years ago

It is still as misconception in the scheduler backend that additional fields need to have unique field names across all registered task.

Imho the most simple solution is to not load all add. fields at once if a task is added / changed, but to reload the view if the task-selector drop-down is changed.

Actions

Copy link

Updated by Michael Stucki almost 11 years ago

Category set to scheduler

Actions

Copy link

Updated by Michael Stucki almost 11 years ago

Project changed from 739 to TYPO3 Core
Category changed from scheduler to scheduler

Actions

Copy link

Updated by Mathias Schreiber almost 10 years ago

Target version set to 7.5
TYPO3 Version set to 4.5
Is Regression set to No

Actions

Copy link

Updated by Benni Mack about 9 years ago

Target version changed from 7.5 to 7 LTS

Actions

Copy link

#10

Updated by Mathias Schreiber about 9 years ago

Description updated (diff)

Actions

Copy link

#11

Updated by Mathias Schreiber about 9 years ago

Description updated (diff)

Actions

Copy link

#12

Updated by Gerrit Code Review almost 8 years ago

Status changed from New 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 https://review.typo3.org/51027

Actions

Copy link

#13

Updated by Gerrit Code Review almost 8 years ago

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

Actions

Copy link

#14