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

[Michael Stucki]

Forget this please, I was wrong about this!
Probably I had already reverted the patch while trying out this. However,
after checking again, it works all fine. Go!

- michael

Michael Stucki wrote:

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