1. 09 May, 2022 1 commit
  2. 07 Apr, 2022 1 commit
  3. 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
  4. 18 Feb, 2022 1 commit
  5. 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
  6. 01 Feb, 2022 1 commit
    • Oliver Klee's avatar
      [BUGFIX] Fix some incorrect usages of Prophecy · f32fdb16
      Oliver Klee authored and Christian Kuhn's avatar Christian Kuhn committed
      With the following changes, we can get rid of a whole bunch
      of warnings from the PHPStan baseline:
      
      1. Now that we are using the Prophecy plugin for PHPStan,
         we don't need type annotations for prophecies anymore.
      2. Prophecies are not instances of the prophesized classes.
         So we need to fix/remove type annotations that incorrectly
         state this, and also move accesses on properties from the
         prophecies to the revelations.
      3. Revelations are not instances of ObjectProphecy. They
         implement ProphecySubjectInterface, but that usually is
         of no relevance to our test classes. So we can simplify
         the type annotations and usually convert those to native
         type annotations.
      4. Have PHPStan ignore false positive related to class aliasing
         (that probably is outside of what PHPStan can do).
      5. Drop extraneous arguments to Argument::any().
      
      Resolves: #96713
      Releases: main, 11.5
      Change-Id: Icfe3ddef89c6bd6edf331c103211ac2ac18f2ef7
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73238
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      f32fdb16
  7. 30 Jan, 2022 1 commit
  8. 04 Jan, 2022 1 commit
  9. 03 Nov, 2021 1 commit
  10. 24 Sep, 2021 1 commit
  11. 11 Sep, 2021 1 commit
  12. 05 Aug, 2021 1 commit
  13. 02 Aug, 2021 1 commit
    • Oliver Bartsch's avatar
      [FEATURE] Introduce TCA type "category" · 1e7653ce
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed
      A new TCA type "category" is introduced, which
      allows to simplify the configuration of category
      TCA columns. Besides the benefit for integrators,
      this allows to deprecate the CategoryRegistry
      in the next step.
      
      The new type can also be used for other use cases.
      Therefore, the TCA option "relationship" is available
      for this TCA type. Besides "manyToMany" (default), this
      can also be set to "oneToOne" or "oneToMany".
      
      Using the new type, FormEngine will always render a
      category tree. This means, no additional `renderType`
      is defined. In such case, TCA type "select" can
      still be used as before, without any limitation. However,
      all relevant places in core are adjusted in this patch.
      
      The category element is rendered through a custom element
      (web component), reducing inline javascript.
      
      Resolves: #94622
      Releases: master
      Change-Id: I1b95c42288b070fa6bac114266f5ad246a045b21
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69899
      
      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>
      1e7653ce
  14. 01 Apr, 2021 1 commit