1. 16 Aug, 2021 3 commits
  2. 13 Aug, 2021 1 commit
  3. 11 Aug, 2021 1 commit
  4. 10 Aug, 2021 3 commits
  5. 20 Jul, 2021 3 commits
  6. 16 Jul, 2021 1 commit
  7. 12 Jul, 2021 2 commits
  8. 06 Jul, 2021 1 commit
  9. 30 Jun, 2021 2 commits
  10. 28 Jun, 2021 1 commit
  11. 22 Jun, 2021 1 commit
  12. 18 Jun, 2021 1 commit
  13. 27 May, 2021 1 commit
  14. 25 May, 2021 1 commit
  15. 12 May, 2021 1 commit
  16. 07 May, 2021 1 commit
  17. 05 May, 2021 1 commit
  18. 04 May, 2021 2 commits
  19. 29 Apr, 2021 1 commit
  20. 29 Mar, 2021 1 commit
    • Oliver Bartsch's avatar
      [BUGFIX] Fix descriptions of selectCheckBox items · 02c42d8a
      Oliver Bartsch authored and Richard Haeser's avatar Richard Haeser committed
      With #91008 the grouping and sorting feature was
      introduced to the TCA select type. As a consequence,
      the select items array key for the help text changed
      from `3` to `4`.
      
      The SelectCheckBox now correctly checks the `4`
      key for the presence of a description.
      
      In v11 the absence of a title value, which is common
      in this scenario, did furthermore lead to TypeError
      on rendering the popover. This is fixed by assigning
      an empty string as default value on initialization of
      the popover options. Otherwise this option would be
      initialized as 'undefined' and then trigger the
      TypeError on sanitizing.
      
      Additionally the TCA properties special=table,
      special=exclude and special=custom are adjusted to
      add the correct value as help text to the items array.
      The value is now added directly as string, as there
      is no need to define the array while only providing
      the description.
      
      As a drive-by-change, the itemsProcFuncs of the
      dashboard and the MFA component do now also add
      the description for their access list field. This
      is done because the dashboard initially defined the
      description already but had to remove it again due
      to this bug, see: #91152. The MFA component also
      just hadn't added it because the bug hadn't been
      resolved at that time.
      
      Resolves: #93331
      Resolves: #92383
      Releases: master, 10.4
      Change-Id: Ie96bcabea88b377490c24b0e60cfca8337e9ec52
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/68616
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Richard Haeser's avatarRichard Haeser <richard@richardhaeser.com>
      Reviewed-by: default avatarJulian Mair <julian.mair94@gmail.com>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Richard Haeser's avatarRichard Haeser <richard@richardhaeser.com>
      02c42d8a
  21. 28 Mar, 2021 1 commit
  22. 26 Mar, 2021 1 commit
  23. 25 Mar, 2021 1 commit
    • Philipp Parzer's avatar
      [BUGFIX] Add pid restriction when getting previousLocalizedRecord · d5366226
      Philipp Parzer authored and Christian Kuhn's avatar Christian Kuhn committed
      Scenario:
      A content element 'ce-1-default' exists on a 'source' page. It
      has a 'free mode' localization 'ce-1-localized'. The localized
      content element thus has l18n_parent=0 (free mode) and
      l10n_source='id-of-ce-1-default' - it has been derived from
      'ce-1-default'.
      
      Now 'ce-1-default' is moved to a different 'target' page. Due to
      free mode, 'ce-1-localized' is NOT moved along with it's localization
      source, but keeps l10n_source='id-of-ce-1-default' (this needs to be
      discussed if we change this) and stays on 'source' page. This is ok.
      
      Now, a new content element 'ce-2-default' is added on 'target' page,
      right below the previously moved 'ce-1-default'. And then, this
      element is localized.
      
      DataHandler now tries to find out where to create this localized
      'ce-2-localized' record relative to other records. It finds the
      localization 'ce-1-localized' due to its l10n_source indicator
      and then creates 'ce-2-localized' after 'ce-1-localized'. On the
      source page!
      So the content element localization ends up on a different page,
      which is of course wrong, misleading and hard to understand!
      
      To fix this, the Datahandler now finds translated content elements
      of a given content element only if it is on the same page. This
      keeps this 'relative-to' magic, and the content element does not
      end up on some foreign page.
      
      Resolves: #92783
      Resolves: #92198
      Releases: master, 10.4
      Change-Id: I104a4b2d59322ec55ad96e37e8d1b3c3fed0e515
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66552
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      d5366226
  24. 24 Mar, 2021 2 commits
  25. 18 Mar, 2021 1 commit
  26. 16 Mar, 2021 3 commits
  27. 12 Mar, 2021 2 commits