[TYPO3-core] RFC: Bug 5704: IRRE - Children on the table pages get the pid of the parent page in pagetree

[Michael Stucki]

Hi Oliver,

from a users perspective: I tested this, created a new page and added some
child records immediately, still before saving the whole page.

The result was that the records have been stored on the parent page of the
new one. Actually it's the same behaviour like we had without this bugfix,
which is also logical of course. However, this will confuse users too much,
and on the other side it seems not easy to fix it.

So why don't you just check if the pid contains "NEW" and display the
following message instead of the IRRE widgets:

| Warning: This page has not been saved yet. Adding elements is not possible
| until it has been saved. 

- michael

> In this special case we are creating a new page and new children on that
> new page. Thus we have the following secenario:
> 1) Record of 'pages' {uid:13, pid:0}
> 2) Record of 'pages' {uid:NEWa12345, pid:13}
> 3) Record of 'tx_myext_child' {uid:NEWe56789, pid:NEW12345}
> 
> The inline TCEform for the 'tx_myext_child' record will be rendered with
> the following AJAX call (this is standard in IRRE, nothing new):
> typo3/alt_doc_ajax.php?ajax[0]=createNewRecord&ajax[1]=data[NEW12345
[pages][NEWa12345][children][tx_myext_child]
> 
> The identifier given by the parameter "ajax[1]" tells TCEforms_inline
> which child record to create for which parent record, the BNF is:
> <irre-ident>    ::= 'data[' <pid> ']' <level-ident> { <level-ident> }
>                     [ <level-role> | <partial-ident> ]
> <level-ident>   ::= '[' <tablename> '][' <uid> '][' <field> ']'
> <level-role>    ::= '_records'
> <partial-ident> ::= '[' <tablename> '][' <uid> ']' <partial-role>
> <partial-role>  ::= '_' ( 'div' | 'header' | 'label' |
>                           'disabled' | 'fields' )
> 
> Thus, it's known that the new child record should get the pid
> "NEW12345". But, this record of the table 'pages' isn't saved yet and
> cannot be checked.
> The table you suggested to check is in this case the grand parent
> (pages:13). If we would now use also the uid of the grand parent for the
> check, it would be nice, but won't prevent from calling the AJAX handler
> directly with a grand parent the user has access to. Thus, it's still
> possible to get the result of TCEforms for the new child record and
> you're suggestion would have had no effect.
> 
> The only way to avoid this is to integrate a new table, e.g.
> 'unsaved_records' which could have the following data:
> {table:'pages', uid:'NEW12345', be_user:10}
> TCEforms will determine if the non-integer pid that is requested to be
> used for the new child record is set in the 'unsaved_records' table.
> Furthermore it has the be ensured that records on the table will be
> cleared after a given time period or when the unsaved record was finally
> correctly saved.
> 
>>> In exactly this case, the check will be done by TCEmain. If the parent
>>> (here a new record on the table pages) could not be create, because of
>>> missing access rights, the child records won't be stored because the pid
>>> with the value "NEW12345678" could not be substituted by a proper
>>> integer.
>> This could be avoided if the pid would have been read from the parent
>> record. The child records should be put on the current page in the
>> backend, or not?
> 
> So what could happen if this check isn't done in this special case (new
> child record on a new unsaved page record)? The back-end user could send
> directly a HTTP POST request to alt_doc_ajax.php and will get an empty
> form for a child record...
> 
> If the back-end user doesn't have access to edit the table with the
> child records at all, the will be nothing rendered. This also means,
> that if the back-end user has access to the child table, he can look at
> the rendered forms on any other page he has access to.
> 
> Furthermore, nothing is saved in this situation because we're still
> talking about TCEforms! And it is possible for every back-end user to
> call alt_doc.php with a data array in HTTP POST directly. TCEmain has to
> handle this - there is nothing TCEforms/TCEforms_inline can do against.
> 
> *Result:*
> If the TYPO3 back-end is used in the normal way (just using the back-end
> user interface) there is nothing bad that happens during editing. If a
> back-end user tries to forge queries and sends requests directly to
> alt_doc.php or alt_doc_ajax.php he might only see an empty input form -
> provided that he has access to the table he is trying to forge. If he
> doesn't have access to that table, he'll see nothing. Fine!
> If the back-end user tries to modify/save data he has no access to, this
> is caught by TCEmain. And this patch doesn't tocuh TCEmain at all!
> 
> So, if you still have objections please share them and it would be real
> great if a solution could be provided then with a new patch! Thanks!
> 
> 
> olly

-- 
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/