1. 16 Aug, 2021 1 commit
  2. 10 Aug, 2021 1 commit
  3. 20 Jul, 2021 1 commit
  4. 16 Jul, 2021 1 commit
  5. 12 Jul, 2021 1 commit
  6. 01 Jul, 2021 1 commit
  7. 30 Jun, 2021 1 commit
  8. 16 Jun, 2021 1 commit
  9. 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
  10. 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
  11. 12 May, 2021 1 commit
  12. 04 May, 2021 1 commit
  13. 27 Apr, 2021 1 commit
  14. 19 Apr, 2021 1 commit
  15. 13 Apr, 2021 1 commit
  16. 09 Apr, 2021 1 commit
  17. 29 Mar, 2021 1 commit
  18. 26 Mar, 2021 1 commit
  19. 24 Mar, 2021 1 commit
  20. 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
  21. 12 Mar, 2021 1 commit
  22. 23 Feb, 2021 1 commit
  23. 08 Feb, 2021 1 commit
  24. 07 Jan, 2021 1 commit
  25. 22 Dec, 2020 1 commit
  26. 19 Dec, 2020 1 commit
  27. 17 Dec, 2020 1 commit
    • Oliver Bartsch's avatar
      [!!!][TASK] Rework shortcut PHP API functionality · e4833fda
      Oliver Bartsch authored and Christian Kuhn's avatar Christian Kuhn committed
      To be able to introduce URL rewrites for the backend,
      the internal handling and registration of the shortcut
      PHP API is reworked.
      
      The Shortcut PHP API previously has the full URL of
      the shortcut target stored in the database. This lead
      to many problems such as shortcuts got invalid as soon
      as their target module changed its route path. Furthermore,
      this required unnecessary functionality like replacing
      tokens on URL creation.
      
      Therefore, a shortcut record now stores only the route
      identifier of the module to link to and necessary arguments
      in two new database columns. A upgrade wizard is in place
      to migrate existing data.
      
      The rework also required to deprecate some methods in
      the ShortcutButton API and a parameter signature change
      of the JavaScript function `TYPO3.ShortcutMenu.createShortcut()`
      which performs the AJAX call to create new shortcuts.
      
      Side effect, this also deprecated the last remains of
      xMOD_alt_doc.php in the core.
      
      Resolves: #93093
      Releases: master
      Change-Id: I07666a299651e4953b4adf2987fcd3469094c288
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67143
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      e4833fda
  28. 12 Dec, 2020 1 commit
  29. 10 Dec, 2020 1 commit
    • Benni Mack's avatar
      [!!!][FEATURE] Refactored Session Handling · 733353c1
      Benni Mack authored
      The AbstractUserAuthentication class handles way too much
      of what it should know / do.
      
      For this reason, a new UserSession object which contains
      basic information needed for everything belonging to a non-fixated
      session, a fixated anonymous session, if a session was evelated,
      or if a session has expired, is kept in there.
      The "SessionManager" should not be used anymore publically
      but slowly dissolve into a SessionBackendManager.
      
      Design goals:
      * UserAuth object should not know about session backends
      * UserAuth should not store sessionData etc. directly in its own object
      * Decouple UserSession info from any properties of UserAuth
      * A UserSessionManager deals with the creation and validation of the UserSession objects. No Session Objects can be created etc outside
      of this class to maintain persistability
      * UserSessionManager also encapsulates ipLocking and the responsible SessionBackend
      
      Final goals to be tackled later:
      * Build a user session object from the request object, and not within the UserAuth object
      * Session Handling can be accessed outside of UserAuth
      * Cookie Handling and Session Handling are separated from UserAuth
      * Load Session information from PSR-7 request instead of $_COOKIE
      
      Resolves: #93023
      Releases: master
      Change-Id: Ia2d8244e433d0f6adf220d443b2c0947f251b5e9
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66935
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      733353c1
  30. 01 Dec, 2020 1 commit
  31. 29 Nov, 2020 1 commit
  32. 28 Oct, 2020 1 commit
  33. 03 Oct, 2020 1 commit
  34. 02 Oct, 2020 1 commit
  35. 04 Sep, 2020 1 commit
  36. 02 Sep, 2020 1 commit
  37. 17 Aug, 2020 1 commit
  38. 07 Aug, 2020 1 commit
  39. 23 Jul, 2020 1 commit
  40. 08 Jun, 2020 1 commit