Project

General

Profile

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 about 13 years ago. Updated over 6 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:
No
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++;
    }
}

to 


// 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)

Blocks TYPO3 Core - Bug #67241: FAL: Update storgae index doesn't save "Storage to index" on first saveClosedMichael Oehlhof2015-06-02

Actions
Actions
Copy link
 #1

Updated by Markus Klein about 13 years ago

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

Actions
Copy link
 #2

Updated by Michael Franzkowiak about 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
 #3

Updated by Francois Suter about 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
 #4

Updated by Michael Franzkowiak about 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
 #5

Updated by Christian Kuhn over 11 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
 #6

Updated by Michael Stucki over 10 years ago

  • Category set to scheduler
Actions
Copy link
 #7

Updated by Michael Stucki over 10 years ago

  • Project changed from 739 to TYPO3 Core
  • Category changed from scheduler to scheduler
Actions
Copy link
 #8

Updated by Mathias Schreiber over 9 years ago

  • Target version set to 7.5
  • TYPO3 Version set to 4.5
  • Is Regression set to No
Actions
Copy link
 #9

Updated by Benni Mack over 8 years ago

  • Target version changed from 7.5 to 7 LTS
Actions
Copy link
 #10

Updated by Mathias Schreiber over 8 years ago

  • Description updated (diff)
Actions
Copy link
 #11

Updated by Mathias Schreiber over 8 years ago

  • Description updated (diff)
Actions
Copy link
 #12

Updated by Gerrit Code Review over 7 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 over 7 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

Updated by Michael Oehlhof over 7 years ago

  • Assignee set to Michael Oehlhof
Actions
Copy link
 #15

Updated by Michael Oehlhof about 7 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions
Copy link
 #16

Updated by Riccardo De Contardi over 6 years ago

  • Status changed from Resolved to Closed
Actions
Copy link

Also available in: Atom PDF