[TYPO3-mvc] Respect storage page ignored on object properties

[Thomas "Thasmo" Deinhamer]

Hello Jochen, thanks a lot for your reply!

Applying your patch doesn't change the resultset.
The query which is missing the storage page
condition is this, where 'tx_hypestore_relation_category_product' is a 
MM table:

==================================================
Array
(
     [keywords] => Array
         (
         )

     [tables] => Array
         (
             [tx_hypestore_relation_category_product] => 
tx_hypestore_relation_category_product
         )

     [unions] => Array
         (
             [tx_hypestore_domain_model_product] => LEFT JOIN 
tx_hypestore_domain_model_product ON 
tx_hypestore_relation_category_product.uid_local = 
tx_hypestore_domain_model_product.uid
         )

     [fields] => Array
         (
             [tx_hypestore_relation_category_product] => 
tx_hypestore_domain_model_product.*
         )

     [where] => Array
         (
             [0] => tx_hypestore_relation_category_product.uid_foreign = ?
         )

     [additionalWhereClause] => Array
         (
             [0] => (tx_hypestore_domain_model_product.type='default' OR 
tx_hypestore_domain_model_product.type='apparel' OR 
tx_hypestore_domain_model_product.type='book' OR 
tx_hypestore_domain_model_product.type='car')
             [1] => tx_hypestore_domain_model_product.deleted=0 AND 
tx_hypestore_domain_model_product.hidden=0 AND 
tx_hypestore_domain_model_product.starttime<=1274999580 AND 
(tx_hypestore_domain_model_product.endtime=0 OR 
tx_hypestore_domain_model_product.endtime>1274999580) AND 
(tx_hypestore_domain_model_product.fe_group='' OR 
tx_hypestore_domain_model_product.fe_group IS NULL OR 
tx_hypestore_domain_model_product.fe_group='0' OR 
(tx_hypestore_domain_model_product.fe_group LIKE '%,0,%' OR 
tx_hypestore_domain_model_product.fe_group LIKE '0,%' OR 
tx_hypestore_domain_model_product.fe_group LIKE '%,0' OR 
tx_hypestore_domain_model_product.fe_group='0') OR 
(tx_hypestore_domain_model_product.fe_group LIKE '%,-1,%' OR 
tx_hypestore_domain_model_product.fe_group LIKE '-1,%' OR 
tx_hypestore_domain_model_product.fe_group LIKE '%,-1' OR 
tx_hypestore_domain_model_product.fe_group='-1'))
             [2] => tx_hypestore_domain_model_product.sys_language_uid 
IN (0,-1)
         )

     [orderings] => Array
         (
             [0] => 
tx_hypestore_relation_category_product.sorting_foreign ASC
         )

     [limit] => Array
         (
         )

)
==================================================

As you can see inside "[additionalWhereClause]" the condition for the 
storage pages are still missing.

Also note, that the actual table beeing queried is the MM table, but in 
the end the query should fetch all fields of the table 
'tx_hypestore_domain_model_product'.

To clarify my situation a bit more:

There are global objects of class 'Category' which are stored in a 
seperate sysfolder. Then I got several page-trees, which all relate to 
one domain each. Each tree/domain has it's own sysfolder with objects of 
class 'Product' which can be assigned to the global categories. The 
content plugin - lets call it 'Shop' - is inserted on every of the 
trees/domains seperately and SHOULD display all categories and the 
products within - but ONLY the products which are stored on the same 
tree/domains.

Let's expect this pages:

[10] Global Categories
[20] Domain J
  [21] Products J
  [22] Shop J
[30] Domain R
  [31] Products R
  [32] Shop R

When I now insert the Shop plugin on page [22] and configure the storage 
page to be "21,10" then it will list all categories BUT also the 
products from this categories which are stored on [31] which is imho bad 
- I only want to display products from [21].

This only happens when using $category->getProducts() but NOT when using 
the product repository. But I have to use the object property to loop 
throu all categories and (sub-loop) all products of each category.

Hopefully it's clear now what the problem is, and I really think that 
the actual situation is not the best. If someone wants to show ALL 
related objects of one object, he should configure the storage page to a 
global parent page and set recursive to 99 to get all objects returned. 
I think setting/defining storage pages is a planned process when 
creating websites, so the sysfolders/pages where objects are stored, are 
well known from beginning - it's not like someone doesn't know the page 
uids beforehand and thus wants to return the objects without respecting 
the storage pages. But if so, someone should just define a 
superglobal/root page uid as storage page.

I'd really like to see this fixed and I would provide a patch, but if 
I'd ever find out how to do it, it will be a mess of a code. So I really 
appreciate your (in sense of you all) help on this.

Thanks a lot,
Thomas


Am 28.05.2010 00:06, schrieb Jochen Rau:
> Hi Thomas,
>
> sorry for jumping into this discussion late. After the the T3CON in
> Dallas I had to proof read the Extbase/Fluid book first.
>
> On 27.05.10 18:31, Thomas "Thasmo" Deinhamer wrote:
>> Okay, I think I found the place where things are either not yet
>> implemented or just not working correctly.
>>
>> In file 'Typo3DbBackend.php' on line 752 in the method
>> 'addAdditionalWhereClause' the query settinsg are checked if the storage
>> page should be set or not. If, then the method 'addPageIdStatement' on
>> line 802 is called which adds the storage pid restriction. But for MM
>> tables it won't do this, because there's an if statement, checking some
>> conditions of the TCA, where MM tables won't pass because they don't
>> match a specific TCA configuration.
>>
>> So I think in the method 'addPageIdStatement' there should be the logic
>> to check if the table is a MM table, and if so, the origin-table should
>> be determined and then it's possible to add the correct where clause.
>>
>> I'm not 100% sure if this will work, but I think it's the problem when
>> querying MM tables with a LEFT JOIN, but fetching the fields of the
>> origin table.
>>
>> Any idea how to extend the method to enable a storage page for left
>> joins?
>
> Fetching *related* records ignoring the PID is the intended behavior
> atm. Somebody must have consciously assigned this object to its parent.
> So I agree to Sebastian here. But this doesn't mean that we are right.
> IMO the whole PID topic is worth to be discussed again to improve or at
> least to clarify the things.
>
> The described behavior is determined in the DataMapper in line 357 as
> you already pointed out:
>
> $query->getQuerySettings()->setRespectStoragePage(FALSE);
>
> You already changed the argument to TRUE (or uncommented the line). And
> here you encountered an issue (thanks for that). The PID constraint was
> not added as it should have been. The issue should be fixed by applying
> the (hopefully) attached patch. Would you mind to test it?
>
> Regards
> Jochen