1. 11 May, 2022 1 commit
  2. 01 Apr, 2022 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] Simplify TCA authMode settings · 2f0338a9
      Christian Kuhn authored and Benni Mack's avatar Benni Mack committed
      To prepare towards a deployable backend group access
      rights system, some of the more obscure options are
      removed to reduce overall complexity.
      
      * TYPO3_CONF_VARS['BE']['explicitADmode'] is finally
        gone: Following a deny list approach is a flawed security
        system. TYPO3's default setting (explicitADmode=allow)
        follows the very common "Least Privileged" principle,
        so editors need to be explicitly given access to a
        CType, as is done with all other permissions.
      
      * The only valid value for TCA config option "authMode"
        on type="select" fields is now "explicitAllow". The
        previous "explicitDeny" value is abandoned following
        the reasoning above. The value "individual" is abandoned
        since it is a very rarely used setting (not a single
        match in TER).
      
      * With authMode="individual" being gone, the select item
        array keys on position six that could be set to "EXPL_DENY"
        and "EXPL_ALLOW" are obsolete.
      
      * Field "explicit_allowdeny" in table be_groups is
        simplified. This was a comma separated list of
        colon separated: "table:field:value:ALLOW/DENY".
        The last "ALLOW" or "DENY" is now obsolete.
      
      The patch removes the above handling from the core. A
      TCA migration scans TCA for invalid options and adapts
      them. An upgrade wizard is in place to clean up the
      be_groups explicit_allowdeny field of existing rows.
      
      Resolves: #97265
      Releases: main
      Change-Id: I545b08fc694e9081ad79e69e7f55f684316e7b0f
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74126
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      2f0338a9
  3. 14 Mar, 2022 1 commit
  4. 09 Mar, 2022 2 commits
  5. 07 Mar, 2022 1 commit
    • Stefan Bürk's avatar
      [TASK] Replace 'CompositeExpression->add()' usage · 81bb030e
      Stefan Bürk authored and Benni Mack's avatar Benni Mack committed
      doctrine/dbal moves their classes forward and deprecated
      some stuff while providing replacement for it. This has
      been early adopted for the core facade classes with #97081
      in a forward-compatible way. Before deprecating the old
      methods core usage have to be replaced.
      
      This patch replaces the usage of 'CompositeExpression::add()'
      with the immutable way using 'with()' with re-assigning the
      returned instance to the used variable.
      
      In general this means that following usage example:
      
        $or = CompositeExpression::or();
        $or->add($queryBuilder->expr()->eq(...));
      
      will be replaced with:
      
        $or = CompositeExpression::or();
        $or = $or->with($queryBuilder->expr()->eq(...));
      
      Alternativly this could be refactored collecting parts in a
      array first and add them later with one 'with()' call or by
      directly creating the 'or()' or 'and()' CompositeExpression
      with the provided parts directly - which would have been a
      larger and harder to review patch. Thus this patch does the
      simple replacement to have minimal changes for easier review
      experience.
      
      Resolves: #97124
      Related: #97081
      Releases: main
      Change-Id: I00fde09593e1c1ccb2949daaec3ee4aa688dda63
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73833
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Nikita Hovratov's avatarNikita Hovratov <nikita.h@live.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Nikita Hovratov's avatarNikita Hovratov <nikita.h@live.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      81bb030e
  6. 05 Mar, 2022 1 commit
  7. 04 Mar, 2022 1 commit
  8. 11 Feb, 2022 1 commit
  9. 07 Feb, 2022 1 commit
    • Oliver Bartsch's avatar
      [!!!][FEATURE] New Module Registration API · 29db88c3
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed
      This change introduces a new way to register
      TYPO3 Backend Modules.
      
      Each module is now registered during build-time
      in a dedicated registry. Therefore, The registration
      is moved from ext_tables.php to the
      Configuration/Backend/Modules.php file.
      
      Accessing the registered modules can be done via
      a central API, the ModuleProvider class. This class
      takes care of access permissions and further
      processing (e.g. module menu generation).
      
      $GLOBALS[TBE_MODULES] is fully removed as no sane
      backwards-compatibility (for a use-case) is available.
      
      A new PSR-14 event BeforeModuleCreationEvent is added,
      which allows to manipulate a module configuration, before
      it is used to create and register the module.
      
      Existing registrations do no longer work. However, to support
      extenion authors in maintaining multiple versions, the previously
      used API methods (e.g. `addModule` and `registerModule`) will
      stay until TYPO3 v13.0. No trigger_error() is used, so extension
      authors use the Extension Scanner to detect usages.
      
      Executed commands:
      
         composer u typo3/cms-styleguide
      
      Resolves: #96733
      Releases: main
      Change-Id: I07f4bc417e6effb1215cf0e373cc60f2b13ba8ad
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73058
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      29db88c3
  10. 18 Jan, 2022 1 commit
    • Stefan Bürk's avatar
      [TASK] Use proper QueryBuilder execute() replacement methods · 597a92fd
      Stefan Bürk authored and Benni Mack's avatar Benni Mack committed
      doctrine/dbal implemented single purpose method to replace the
      compound 'execute()' in QueryBuilder to avoid the incompatible
      return typehint tuple of 'Doctrine\DBAL\Result|int' in favour
      of 'executeQuery()' and 'executeStatement()' which was added
      forward-compatible with #96247 marking the old one internal
      but not deprecated for now to keep a eventually longer grace
      period to mitigate for extensions developers.
      
      This patch however goes through the core and replace these
      methods to be clean as possible and is a first preparation
      to remove the 'checkThisOnly' option from phpstan which are
      swallowed by this option.
      
      * replace 'execute' with 'executeQuery()' for select and
        count queries generating results ('Doctrine\DBAL\Result').
      * use 'executeStatement()' for insert, update and delete
        queries return affected rows as return value (int)
      * adjust return typehints to match the single return type
        signature on really minor places to match the return type
        of the wrapped replaced execute method.
      * replace one really old 'exec()' from connection with
        corresponding replacement method along the way.
      * add several todos on two places which are weird and do
        not make any sense for further investigation and fixing,
        as declared as out-of-the-scope for this wide-area patch.
      
      Resolves: #96551
      Related: #96247
      Related: #96521
      Releases: main, 11.5
      Change-Id: Ie8d40f3882f1694ab7f7e5053729fa1c798a9c5f
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73032
      
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      597a92fd
  11. 08 Jan, 2022 1 commit
  12. 04 Jan, 2022 1 commit
  13. 20 Dec, 2021 1 commit
  14. 07 Dec, 2021 1 commit
  15. 05 Dec, 2021 1 commit
  16. 19 Nov, 2021 1 commit
  17. 15 Nov, 2021 1 commit
  18. 27 Oct, 2021 1 commit
  19. 11 Oct, 2021 2 commits
  20. 24 Sep, 2021 3 commits
  21. 22 Sep, 2021 1 commit
  22. 24 Aug, 2021 1 commit
  23. 23 Aug, 2021 1 commit
  24. 08 Aug, 2021 1 commit
  25. 03 Aug, 2021 1 commit
  26. 29 Jul, 2021 2 commits
  27. 28 Jul, 2021 1 commit
  28. 22 Jul, 2021 1 commit
  29. 01 Jul, 2021 1 commit
  30. 28 Jun, 2021 1 commit
  31. 01 Jun, 2021 1 commit
  32. 27 May, 2021 1 commit
  33. 26 May, 2021 1 commit
  34. 14 May, 2021 1 commit
  35. 11 Mar, 2021 1 commit