1. 16 Aug, 2021 1 commit
  2. 10 Aug, 2021 1 commit
  3. 20 Jul, 2021 2 commits
  4. 16 Jul, 2021 1 commit
  5. 12 Jul, 2021 2 commits
  6. 09 Jul, 2021 1 commit
  7. 01 Jul, 2021 1 commit
  8. 30 Jun, 2021 1 commit
  9. 29 Jun, 2021 1 commit
    • Oliver Bartsch's avatar
      [BUGFIX] Extract switch user handling from EXT:beuser · 70f8559a
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed
      The switch user handling was previously placed in EXT:beuser,
      more precisely in the BackendUserControllers' indexAction.
      It was therefore necessary to link to the extbase based
      controller with a mix of prefixed arguments and the non
      prefixed "switchUser" argument. Latter was internally
      evaluated with GU:_GP(). This means, switching users was
      done via GET requests in an extbase action, but only in
      case a non extbase prefixed argument was set.
      
      In #94209 this got worse when the BackendUserGroupController
      was merged into BackendUserController. Since this controller
      features a "remember my last action" functionality, switch user
      could no longer reliably be triggered. The evaluation of the
      non extbase prefixed "switchUser" argument only took place in
      the "user listing" (indexAction) and the success of the call
      therefore depended on the users' last called action, as this
      action was automatically used.
      
      This patch now extracts the switch user functionality from
      EXT:beuser into a dedicated EXT:backend controller, featuring
      two ajax routes "/switch/user" and "/switch/user/exit". Both
      accessible via POST requests only. To trigger those requests,
      a new JS module "TYPO3/CMS/Backend/SwitchUser" is introduced.
      This also allows to completely remove the logout hook by using
      the concrete markup (custom element) for the "exit" button.
      
      Resolves: #94426
      Related: #94209
      Releases: master
      Change-Id: I556b323fe6ae77cf696e7e34dbbe269eb4f9927a
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69635
      
      
      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>
      70f8559a
  10. 27 Jun, 2021 1 commit
  11. 16 Jun, 2021 1 commit
  12. 08 Jun, 2021 1 commit
    • Oliver Bartsch's avatar
      [FEATURE] Simplify sharing of backend urls · 24f43811
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed
      Atfer a lot of preperation in #93048 and #93988,
      it's finally possible to share URLs to TYPO3 backend
      modules. Even special modules such as FormEngine.
      
      To ease the use for editors, the ShortcutButton
      is extended for a new option. If enabled, which
      is the default behaviour, the shortcut button
      in the module header is replaced. The new button
      allows to open a dropdown with the additional
      possibility to copy the URL of the current
      page to the operating systems' clipboard. Next
      to the already exisiting "Add shortcut" option.
      
      Since those URLs should not contain the user
      specific token, the UriBuilder features a new
      constant "SHAREABLE_URL". If set as $referenceType
      in one of the supporting methods, e.g. buildUriFromRoute(),
      an absoulte URL without the token is returned.
      
      To copy the URL to the operating systems' clipboard,
      a new web component "CopyToClipboard" is introduced.
      This component is added without any dependency to
      the URL sharing functionality and can therefore be
      freely used for other backend components as well.
      
      For the new button, the font awesome "share-alt"
      icon is registered in the IconRegistry.
      
      Resolves: #93921
      Releases: master
      Change-Id: Id1dcfe1f2af764fbe000659ddb49a7369322d5b6
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69338
      
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      24f43811
  13. 31 May, 2021 1 commit
    • Oliver Bartsch's avatar
      [TASK] Change password reset functionality · 12737d31
      Oliver Bartsch authored and Richard Haeser's avatar Richard Haeser committed
      In case administrators don't want their users to
      initiate the reset password process, they have to
      set the global configuration option "passwordReset"
      to false.
      
      This however also prevents administrators from
      using the cli command or the action in the backend
      user module.
      
      Therefore, some things changed in the password
      reset implementation:
      
      - `passwordReset` now only affects the login screen
      - The CLI command is always enabled (requires shell
        access since the command is not schedulable)
      - Initiating password reset in the backend can be
        managed separately with a new user TSconfig option
      
      Also the descriptions of the global configuration
      options are adjusted. Actually `passwordResetForAdmins`
      previously mentioned that setting this to FALSE will
      only affect the login screen, which was not the case.
      It always affected all places.
      
      In the end, this enables administrators to be more
      precise when configuring the password reset functionality
      in their installations.
      
      Resolves: #91496
      Releases: master
      Change-Id: Ic74080adffbaf55f82189dffddb93fdd601034e2
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69268
      
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Tested-by: Richard Haeser's avatarRichard Haeser <richard@richardhaeser.com>
      Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Reviewed-by: Richard Haeser's avatarRichard Haeser <richard@richardhaeser.com>
      12737d31
  14. 26 May, 2021 1 commit
  15. 20 May, 2021 2 commits
  16. 12 May, 2021 1 commit
  17. 11 May, 2021 1 commit
  18. 04 May, 2021 1 commit
  19. 27 Apr, 2021 2 commits
  20. 19 Apr, 2021 2 commits
  21. 16 Apr, 2021 1 commit
  22. 13 Apr, 2021 1 commit
  23. 09 Apr, 2021 1 commit
  24. 01 Apr, 2021 1 commit
  25. 29 Mar, 2021 2 commits
  26. 26 Mar, 2021 1 commit
  27. 25 Mar, 2021 1 commit
  28. 24 Mar, 2021 1 commit
  29. 16 Mar, 2021 1 commit
    • Benni Mack's avatar
      [FEATURE] Introduce TCA type "language" · 954a3f08
      Benni Mack authored and Christian Kuhn's avatar Christian Kuhn committed
      A new TCA type "language" is added, in order to make life easier
      to set up new TCA. The main issue (as can be seen in core already)
      is that each TCA adds different implementations on how to deal with
      "-1". Now "-1" is added for any record except "pages", where the
      "-1 / All Languages" concept is not implemented.
      
      In addition, this decouples the select type from sys_language,
      effectively reducing the logic where a direct access is necessary
      to the "sys_language" table.
      
      This effectively also removes the now mis-use of `foreign_table`
      from the TCA "languageField" field by properly handling languages
      internally. This furthermore makes any relation handling superfluous,
      reducing quite an amount of code and complexity in the DataHandler.
      
      Instead, all columns, defined as "[ctrl][languageField]", are now
      automatically migrated to the new "type=language", with no specific
      configuration, as TYPO3 is managing this field, taking care of the
      user specific configuration.
      
      Furthermore, are all columns, using the “special=languages” option,
      migrated to the new TCA type. This allows to get rid of this special
      case as well, reducing complexity in FormEngine and DataHandler.
      
      The new TCA type also properly handles the field for records on
      root level, or on a page outside of a site context. The only
      exception is the `allowed_languages` field in be_users and
      be_groups, where a new itemsProcFunc is used.
      
      Resolves: #57082
      Releases: master
      Change-Id: Ic4878326c0cdc6ce1f233fa29f07419bf6b572a4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/60293
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      954a3f08
  30. 12 Mar, 2021 1 commit
  31. 02 Mar, 2021 1 commit
  32. 23 Feb, 2021 1 commit
  33. 08 Feb, 2021 1 commit
  34. 17 Jan, 2021 1 commit