Project

General

Profile

Actions

Feature #51245

closed

Epic #86307: Extbase allows to fetch deleted/hidden records (respects ignoreEnableFields)

DataMapper should use defaultquerySettings from repository

Added by Alexander Jahn over 10 years ago. Updated over 3 years ago.

Status:
Rejected
Priority:
Should have
Category:
Extbase
Target version:
-
Start date:
2013-08-22
Due date:
% Done:

100%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

Hi there!

I stumbled upon a problem with the DataMapper.

Currently it is not possible for Extbase to inject hidden records in a model.
While this might not be a problem for frontend use, it certainly is when using extbase in the backend.

Currently, when Extbase builds a query to select an object in DataMapper::getPreparedQuery, it does not use the query created by the corresponding repository where RespectEnableFields might be set.
Instead it creates a plain query with RespectStoragePage and RespectSysLanguage set to false. There is no possibility to set RespectEnableFields.

However, the defaultQuerySettings of the corresponding repository might be quite different.

My patch adresses this mismatch by first trying to get the query from a possible repository. This query uses defaultQuerySettings.
Only if no repository is found, a plain query is created.

The patch is for Extbase 4.7 but Extbase 6.1 uses the same method so my patch should apply there as well


Files

DataMapper.patch (1.76 KB) DataMapper.patch patch for dataMapper Alexander Jahn, 2013-08-22 10:19
DataMapper.patch (1.77 KB) DataMapper.patch fixed patch Alexander Jahn, 2013-08-22 10:23

Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Bug #59641: Make Extbase use Repository for internal callsRejected2014-06-18

Actions
Precedes TYPO3 Core - Feature #51250: getObjectByIdentifier should use defaultQuerySettings from repositoryClosed2013-08-232013-08-23

Actions
Actions #1

Updated by Alexander Jahn over 10 years ago

Found a small problem in my patch.

Actions #2

Updated by Alexander Opitz over 9 years ago

  • Status changed from New to Needs Feedback

Hi,

was this issue fixed or does it still exists?

Actions #3

Updated by Alexander Jahn over 9 years ago

Yes, this issue still exists in TYPO3 6.2.

Actions #4

Updated by Alexander Opitz over 9 years ago

  • Project changed from 534 to TYPO3 Core
  • Category changed from Extbase: Generic Persistence to Extbase
  • Status changed from Needs Feedback to New
  • Target version changed from Extbase 4.7 to 7.0
Actions #5

Updated by Gerrit Code Review over 9 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 http://review.typo3.org/35328

Actions #6

Updated by Gerrit Code Review over 9 years ago

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

Actions #7

Updated by Mathias Schreiber over 9 years ago

  • Target version changed from 7.0 to 7.1 (Cleanup)
Actions #8

Updated by Gerrit Code Review about 9 years ago

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

Actions #9

Updated by Gerrit Code Review about 9 years ago

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

Actions #10

Updated by Gerrit Code Review about 9 years ago

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

Actions #11

Updated by Gerrit Code Review about 9 years ago

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

Actions #12

Updated by Benni Mack almost 9 years ago

  • Target version changed from 7.1 (Cleanup) to 7.4 (Backend)
Actions #13

Updated by Susanne Moog over 8 years ago

  • Target version changed from 7.4 (Backend) to 7.5
Actions #14

Updated by Benni Mack over 8 years ago

  • Target version changed from 7.5 to 8 LTS
Actions #15

Updated by Gerrit Code Review over 8 years ago

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

Actions #16

Updated by Anja Leichsenring about 7 years ago

  • Status changed from Under Review to New

can someone please verify this issue is still valid? I am under the impression it was solved meanwhile.

Actions #17

Updated by Riccardo De Contardi about 7 years ago

  • Target version changed from 8 LTS to 9.0
Actions #18

Updated by Susanne Moog about 6 years ago

  • Target version deleted (9.0)
Actions #19

Updated by Tymoteusz Motylewski over 5 years ago

  • Parent task set to #86307
Actions #20

Updated by Alexander Schnitzler almost 4 years ago

  • Status changed from New to Rejected

This ticket has been rejected since the DataMapper must never use the repository settings, especially since the DataMapper can can be called in different contexts. We are dealing with the backend here and it's the responsibility of the user to create custom queries that respect deleted/hidden in a custom way. The default is that Extbase does not apply enable fields in the backend for good reasons.

Actions #21

Updated by Artur Cichosz over 3 years ago

  • Assignee set to Alexander Schnitzler

Alexander Schnitzler wrote:

This ticket has been rejected since the DataMapper must never use the repository settings, especially since the DataMapper can can be called in different contexts. We are dealing with the backend here and it's the responsibility of the user to create custom queries that respect deleted/hidden in a custom way. The default is that Extbase does not apply enable fields in the backend for good reasons.

Hi,

I just stumbled across this issue in a custom TYPO3 backend controller, where in the model repository I try to fetch some records with visibility dates set.
This is my code.

    /**
     * @param $electionUid
     * @return object
     */
    public function findByUidIgnoreEnableFields($electionUid) {

        /** @var $querySettings \TYPO3\CMS\Extbase\Persistence\Generic\Typo3QuerySettings */
        $querySettings = $this->createQuery()->getQuerySettings();
        $originalQuerySettings = $querySettings;

        // define the enablecolumn fields to be ignored
        // if nothing else is given, all enableFields are ignored
        $querySettings->setIgnoreEnableFields(TRUE);

        // define single fields to be ignored
        $querySettings->setEnableFieldsToBeIgnored(array('disabled','starttime','endtime'));

        $this->setDefaultQuerySettings($querySettings);

        $result =  $this->findByUid($electionUid);

        // reset query settings to original state
        $this->setDefaultQuerySettings($originalQuerySettings);

        return $result;

    }

The entity with the ID I ask for exists but the query returns null because 'endtime' is in the past.
And the reason is exactly what the OP described.

The code above worked in TYPO3 7 but it stopped working in TYPO3 8.

I can not really follow the statement "We are dealing with the backend here and it's the responsibility of the user to create custom queries".
I can remember the fact, that we can use almost the same extbase controller (except where TSFE is used of course) in frontend and in backend, being praised as a great feature of extbase and recent TYPO3 backend core.

How I understand you statement is that we should be limited to raw/custom queries in backend module controllers.
Is it correct?

I do not find it obvious to always keep in mind in which context we are, to be allowed to use built in repository methods like -findByUid() or ->findAll().

Actions

Also available in: Atom PDF