1. 19 Jun, 2022 1 commit
  2. 07 Mar, 2022 1 commit
  3. 20 Feb, 2022 1 commit
  4. 17 Feb, 2022 1 commit
  5. 16 Feb, 2022 1 commit
    • Benjamin Franzke's avatar
      [TASK] Use @typo3/ as ES6 module namespace · 7a41f905
      Benjamin Franzke authored and Georg Ringer's avatar Georg Ringer committed
      Switch from TYPO3/CMS/ExtName/ to @typo3/ext-name/ module
      namespace in all TypoScript modules in order to
      use the common "scoped package" syntax as known from npmjs.
      
      This will allow TYPO3 TypeScript declarations to be
      published to @typo3/* packages on npmjs.com at some point,
      allowing extension authors to require these as npm/yarn
      dependencies to be able to use TypeScript type declarations
      when developing against the TYPO3 JavaScript API.
      
      While at it, the naming convention of JavaScript modules is
      also switched to use lowercase-dashed form. This is to adhere
      to the common used naming convention in the npm-world.
      Also @typo3/core/ajax/ajax-request.js simply looks better than
      a mixed form @typo3/core/Ajax/AjaxRequest.js would be.
      
      All existing RequireJS module identifiers are mapped
      to the new naming syntax in the requirejs-to-es6 bridge:
      For example a requirejs call to
        TYPO3/CMS/T3editor/Element/CodeMirrorElement
      will transparently be transformed to the new sc...
      7a41f905
  6. 15 Feb, 2022 1 commit
    • Benjamin Franzke's avatar
      [TASK] Convert all static RequireJS calls to native ES6 modules · 1ea56b32
      Benjamin Franzke authored and Georg Ringer's avatar Georg Ringer committed
      All static RequireJS calls (static string argument) are migrated to
      native ES6 modules.
      
      Excluded is CodeMirrorElement which still needs RequireJS to be
      available for loading CodeMirror and it's modules. CodeMirror
      migration to ES6 will be a separate step by upgrading from v5 to v6.
      
      Manual modifications in Form/Element/AbstractFormElement.php to keep
      JavaScriptModule flags for registerCustomEvaluation call-conversions.
      Also JavaScriptRenderer.php to is patched always include
      the EXT:core importmap whenever the JavaScriptItemHandler is used
      (required for the dependency to "JavaScriptItemProcessor.js").
      
      All other changes have been performed with the following commands:
      
        git grep -l "loadRequireJsModule('TYPO3/CMS" | \
          grep -v /Documentation/Changelog | \
          grep -v ActionMenuViewHelper.php | \
          xargs sed -i '/CodeMirrorElement/!'"s/->loadRequireJsModule('\\(TYPO3\/CMS\/[^']*\\)')/->loadJavaScriptModule('\\1.js')/g"
      
        git grep -l "JavaScriptModuleInstruction::forRequireJS('TYPO3/CMS" | \
          grep -v /Documentation/Changelog | \
          grep -v JavaScriptRendererTest.php | \
          xargs sed -i '/CodeMirrorElement/!'"s/JavaScriptModuleInstruction::forRequireJS('\\(TYPO3\/CMS\/[^']*\\)'/JavaScriptModuleInstruction::create('\\1.js'/g"
      
        git grep -l "JavaScriptModuleInstruction::forRequireJS($" | \
          grep -v /Documentation/Changelog | \
          grep -v Form/Element/AbstractFormElement.php | \
          xargs sed -i -e '/CodeMirrorElement/!s/::forRequireJS/::create/' -e "s/^\([ ]*\)'\\(TYPO3\/CMS\/[^']*\\)'/\\1'\\2.js'/g"
      
        sed -i "s/'\\(TYPO3\/CMS\/[^']*\\)'/'\\1.js'/g" typo3/sysext/backend/Tests/Functional/Form/MfaInfoElementTest.php
      
        # Same migration as already started in #96607
        git grep -l includeRequireJsModules= | \
          grep -v /Documentation/Changelog/ | \
          grep -v PageRendererViewHelper.php | \
          xargs sed -i \
            -e 's/includeRequireJsModules=/includeJavaScriptModules=/' \
            -e "s/\\([0-9]: *'TYPO3\\/CMS\\/.*\\)'/\\1.js'/g"
      
      Resolves: #96570
      Related: #96323
      Related: #96607
      Releases: main
      Change-Id: Idc81d6b4d58168f0bfafc3e9e4ad46fa1e5f27e7
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73027
      
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      1ea56b32
  7. 09 Feb, 2022 1 commit
  8. 05 Feb, 2022 1 commit
  9. 04 Feb, 2022 1 commit
  10. 04 Dec, 2021 1 commit
  11. 01 Dec, 2021 1 commit
  12. 24 Sep, 2021 1 commit
  13. 16 Sep, 2021 1 commit
  14. 30 Jun, 2021 1 commit
  15. 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
  16. 27 May, 2021 1 commit
    • Christian Kuhn's avatar
      [TASK] Deprecate ext:backend ModuleLayout view helpers · 5a456090
      Christian Kuhn authored
      A while after the PHP based ModuleTemplate API has been
      introduced back in 2015, a couple of fluid view helpers
      have been added to ext:backend as a second way to handle
      full backend module content like the doc header.
      It found an example use in ext:beuser.
      
      Development however stopped at this point, the provided
      view helpers are only a sub set of the PHP based API and
      they didn't find broader use within the core - all other
      backend modules stick to the ModuleTemplate based API.
      
      On a structural level, those view helpers are questionable:
      They move functionality to the view component which is
      arguably more a controller task. The ext:beuser module
      proofes this since it had to assign controller knowledge
      like the current action and controller name to the view
      in order to render the doc header module down and shortcut
      buttons.
      
      The patch drops usages of these view helpers in ext:beuser,
      plus the minor usages of the outer ModuleLayout view helper
      in ext:install and ext:belog, substitutes them with the
      PHP ModuleTemplate API within controllers, and deprecates
      the full set of ModuleLayout view helpers.
      
      The change sharpens our separation between controller and
      view: The "outer" module handling like doc header buttons
      and menus are tied to controller logic and should be
      located there, while the module body is rendered by a
      fluid view.
      
      As a bonus, a couple of issues within ext:beuser are
      fixed along the way, since they can now be easily solved
      and were rather hard to tackle with the view helper based
      approach:
      * The beuser module now remembers state and jumps to
        for instance the group sub module when a user selected
        this last. This is now in line with many other backend
        modules that do the same.
      * Shortcuts to single user details work.
      * The main doc header drop down can now contain all possible
        sub modules, including those that are available only
        indirectly, for instance the single user details view.
        This is good when calling these from shortcuts.
      
      Change-Id: Idef3aa6975e97677c1da0cef57f70c855bd2ea9f
      Resolves: #94209
      Releases: master
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69269
      
      
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      5a456090
  17. 26 May, 2021 1 commit
  18. 30 Apr, 2021 1 commit
  19. 07 Jan, 2021 2 commits
    • Oliver Bartsch's avatar
      [TASK] Fetch route from request instead of GET parameter · b52f67b6
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed
      The "route" GET parameter is deprecated since #93048.
      Therefore the route path has now to be fetched from the
      request object instead.
      
      This patch replaces all places in core where the route
      is still fetched via GET. It's currently often necessary
      to access $GLOBALS['TYPO3_REQUEST'] therefore, since the
      request object is not always present at those places. This
      will be tackeled in upcoming patches.
      
      Resolves: #93158
      Releases: master
      Change-Id: I6e163919b19484171b6ebf8087fdc650cf977c9c
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67355
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.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>
      b52f67b6
    • Benjamin Franzke's avatar
      [TASK] Propagate "immediate" responses through the middleware stack · f179a57f
      Benjamin Franzke authored and Benni Mack's avatar Benni Mack committed
      When a controller finds some pre-requisites of the called
      action are not fulfilled, it can create an 'early' response
      and throw it as ImmediateResponseException. This exception
      bypasses the middleware stack, and is caught in the Application
      to emit the response. This is a big win in contrast to
      die/exit calls.
      
      Some middlewares however expect to be always called when the
      response bubbles up. Good examples are 'locking' middlewares:
      They set up a lock when called, dispatch to inner middlewares,
      and tear town the lock when a response is retrieved.
      
      The tear down code of those middlewares is bypassed when
      a controller throws an ImmediateResponseException.
      
      The patch introduces a second exception: PropagateResponseException.
      This one is caught by a new very inner middleware positioned at the
      end of the middleware stack, just before the request is dispatched
      to some controller. It then sends the response up the outer
      middlewares. This allows middlewares like a 'locking' middleware
      to do it's job without being bypassed, and at the same time
      allows a controller to bypass any further local processing by
      throwing such a response exception.
      
      ImmediateResponseException exists as before and can still be used
      to directly bypass the middleware stack and is kept as safety net
      in case a PropagateResponseException is thrown within a middleware.
      PropagateResponseException therefore extends ImmediateResponseException.
      
      It's however discouraged to throw ImmediateResponseException from
      within controllers - they require knowledge on what middlewares
      do in their 'tear down' part and there shouldn't be a reason to
      bypass them.
      
      Middleware/BackendUserAuthenticator is adapted to properly
      handle ImmediateResponseException that would have been thrown
      BackendUserAuthentication::backendCheckLogin(). BackendUserAuthentication
      is therefore refactored to allow to call the backend login
      initialization without (duplicate) login check.
      This allows to propagate redirect/maintenance responses.
      
      Releases: master
      Resolves: #93007
      Change-Id: I291d9d532e7fa289b803e5eef38b23402e57e8ba
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67042
      
      
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: default avatarTYPO3com <noreply@typo3.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>
      f179a57f
  20. 05 Jan, 2021 1 commit
  21. 04 Jan, 2021 1 commit
  22. 22 Dec, 2020 1 commit
  23. 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
  24. 07 Dec, 2020 2 commits
  25. 05 Dec, 2020 1 commit
  26. 30 Nov, 2020 1 commit
  27. 18 Nov, 2020 1 commit
  28. 17 Nov, 2020 1 commit
  29. 06 Nov, 2020 1 commit
    • Alexander Schnitzler's avatar
      [!!!][TASK] Make Extbase handle PSR-7 responses only · 23b09b8f
      Alexander Schnitzler authored and Daniel Goerz's avatar Daniel Goerz committed
      With this patch, Extbase does no longer handle/return
      extbase responses whose api was defined by the extbase
      ResponseInterfacer. Instead, Extbase does create a PSR-7
      compatible response object and passes it back through
      the request handling stack.
      
      Since PSR-7 requires response objects to be immutable,
      the response object is no longer accessible as property
      of class ActionController. It is also no longer accessible
      through the ControllerContext class. In fact, the response
      is completely hidden from the user and can no longer be
      changed.
      
      To address this issue, an upcoming patch will enable users
      to return user controlled responses from within controller
      actions instead of just returning content strings. User will
      then be forced to return response objects with the content
      and all necessary headers, such as the content-type, set.
      
      Since the Response class has been deleted, it is no longer
      usable in user land code. It should be replaced with PSR-7
      compatible response objects to stay compatible with response
      handlers of both the core and extbase.
      
      Releases: master
      Resolves: #92502
      Change-Id: I4d5dc1478be6dd25b43f6249139eeb4ce5cc3094
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66070
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      23b09b8f
  30. 23 Oct, 2020 1 commit
    • Alexander Schnitzler's avatar
      [!!!][TASK] Request processing chain must return a response object · 723cacda
      Alexander Schnitzler authored and Benni Mack's avatar Benni Mack committed
      This patch introduces a proper request/response handling chain. That
      means, that Extbase no longer creates a response object early, passes
      it through the request handler and dispatcher into the controller and
      expects it to be altered there.
      
      Instead, request handlers, the dispatcher and controllers only get
      passed a request object and controllers are then responsible for
      creating and returning a response.
      
      This change is preparatory work for the introduction of PSR-7 responses
      in Extbase. Those responses are immutable and can no longer passed by
      reference through the stack. Instead, the controller must return the
      desired response along with its state down the stack while remaining
      unaltered.
      
      This patch is considered breaking because it changes several method
      signatures of public classes and interfaces.
      
      Still, it is quite unlikely to be struck by this change when using
      the public api of Extbase and not overriding classes such as the
      ActionController.
      
      Releases: master
      Resolves: #92513
      Change-Id: I3ab7846268ea68727a2f57eea69328b85be4f5e6
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66079
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      723cacda
  31. 27 Sep, 2020 1 commit
  32. 05 Sep, 2020 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] Refactor create bookmark handling · 5be7b805
      Christian Kuhn authored and Anja Leichsenring's avatar Anja Leichsenring committed
      The backend shortcut / bookmark handlig API was designed to
      hand over relevant get/post arguments as key only (eg. 'id').
      The underlying code then pulled values from GET/POST or from
      SOBE->MOD_SETTINGS. This is ugly, there shouldn't be such
      magic: Only controllers know relevant keys and values, so
      it should hand them over directly to the shortcut API.
      
      The patch changes this:
      * Old and unused ViewHelper f:be.buttons.shortcut is deprecated.
      * ViewHelper be:moduleLayout.button.shortcutButton deprecates
        argument 'getVars' and adds new argument 'arguments'.
      * Class ShortcutButton has a new setter 'setArguments' that
        accepts all relevant argument key/value pairs to create a
        shortcut. Existing get/set related methods are deprecated.
      * Helper methods 'makeShortcutIcon' and 'makeShortcutUrl' of
        class ModuleTemplate are deprecated and implemented in class
        ShortcutButton directly.
      * All core usages are adapted to new API.
      * Shortcut handling was the last core usage of SOBE, so last
        $GLOBALS['SOBE'] = $this assignments can be finally removed.
      
      Impact:
      * Shortcuts to modules not directly reachable via main menu
        do not work due to limits of the module registration API. An
        example is the 'create multiple pages' controller. This issue
        exists before the patch, affected controllers no longer render
        a shortcut button for now.
      * The old code usually added the 'route' argument twice for shortcuts.
        This has been resolved. As a side effect, the comparison if a
        shortcuts exists (yellow shortcut icon) fails currently for existing
        shortcuts when the patch is applied: The comparison relies on
        direct string equality since shortcuts always store the final url in
        the database. This storage strategy should be changed with another
        patch that will solve the 'no yellow icon' issue at the same time.
      
      Change-Id: I3ccd2b8f6adab8e7780c5f9911fdea013ccfa99b
      Resolves: #92132
      Releases: master
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65503
      
      
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      5be7b805
  33. 31 Aug, 2020 1 commit
  34. 17 Apr, 2020 1 commit
  35. 15 Apr, 2020 1 commit
  36. 04 Apr, 2020 1 commit
  37. 06 Mar, 2020 1 commit
    • Benni Mack's avatar
      [FEATURE] Reset password for backend users · 24c59a3f
      Benni Mack authored and Georg Ringer's avatar Georg Ringer committed
      This feature adds a link on TYPO3 Backend's login form
      to reset a backend users' password if the user has forgotten the password.
      
      Key changes:
      * Only enabled for backend users with an email address and a password set
      * Enabled by default but can be disabled completely
      * Optionally only works for non-admins via TYPO3_CONF_VARS
      * Only send out emails to users within the system, but no information disclosure
      * If multiple valid users have the same email address, a different email is sent out
      * TCA be_users.email is not set to eval=email (due to backwards-compatibility)
      * Password resets are only valid for 2 hours (non-configurable)
      * Not extensible for third-party authentication methods yet
      * Rate limiting is enabled per email address for 3 attempts per 30mins (non-configurable)
      * When logging in, all previous tokens are removed
      * When requesting multiple resets, only the last email is valid
      * A CLI command "backend:resetpassword $backendUrl $emailAddress" sends out an email as well from admins
      * Admins can trigger a password reset for users in the BE User module
      
      Resolves: #89513
      Releases: master
      Change-Id: I9a146d5a9db176d24f2223c5eafb0fb42861e93f
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/63385
      
      
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      24c59a3f
  38. 22 Feb, 2020 1 commit