1. 12 Dec, 2020 1 commit
  2. 10 Dec, 2020 2 commits
  3. 07 Dec, 2020 1 commit
  4. 26 Nov, 2020 2 commits
  5. 16 Nov, 2020 1 commit
  6. 12 Nov, 2020 1 commit
    • Benni Mack's avatar
      [!!!][TASK] Do not create new version placeholders in workspaces anymore · 74899ecf
      Benni Mack authored
      Creating a new record in a workspace adds two database rows.
      
      One that is the "placeholder", which - since v10.4 - contains
      the same metadata as the other record:
      
      * t3ver_wsid = workspaceID
      * t3ver_oid = 0 (simulating behavior of an "online pendant record")
      * t3ver_state = 1
      
      And the "versionized" record, identified by:
      
      * t3ver_wsid = workspaceID
      * t3ver_oid = uid of the new placeholder record
      * t3ver_state = -1
      
      As of TYPO3 v10, the first record is not needed anymore,
      the versioned record can be queried directly, however, since
      the relations (except MM) point to the placeholder record,
      this one is kept.
      
      As result, only one record is created from now on:
      
      * t3ver_wsid = workspaceID
      * t3ver_oid = 0 (no online counterpart)
      * t3ver_state = 1
      
      On reading, the record is queried directly (no overlay needed anymore!)
      with the existing Database Doctrine Restrictions. On publishing, the
      record just gets the state/stage/wsid set and is "live".
      
      This brings fundamental benefits:
      
      * No overlays needed when querying
      * Fewer database records (placeholders are not helpful)
      * Conceptual problems with placeholder and shadowed fields are removed
      
      Resolves: #92791
      Releases: master
      Change-Id: I0288cc63fe72d8442d586f309bd4054ac44e829b
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65587
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-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>
      74899ecf
  7. 09 Nov, 2020 1 commit
  8. 22 Oct, 2020 1 commit
  9. 20 Oct, 2020 1 commit
  10. 19 Oct, 2020 1 commit
  11. 02 Oct, 2020 1 commit
  12. 23 Sep, 2020 1 commit
  13. 17 Sep, 2020 1 commit
  14. 11 Sep, 2020 1 commit
  15. 05 Sep, 2020 1 commit
  16. 04 Sep, 2020 1 commit
  17. 03 Sep, 2020 1 commit
  18. 27 Aug, 2020 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] Drop TCA [ctrl][thumbnail] and user uc[thumbnailsByDefault] · ae39eb5a
      Christian Kuhn authored and Anja Leichsenring's avatar Anja Leichsenring committed
      Setting TCA[$someTable]['ctrl']['thumbnail'] to some image related
      column made the list module show attached images as preview.
      Until core v8, this has been used for tt_content and has been
      dropped for this table because two different fields (images, media)
      are used and the setting could not cope with that.
      For extensions with own tables, this setting has been used
      very seldom. It also partially destroys the list module view.
      
      The patch drops evaluation of this ctrl setting in the list module.
      With this gone, the 'thumbnailsByDefault' setting of the user settings
      module only affects the file list module. The file list module has
      it's own checkbox to toggle image preview rendering, so the setup module
      checkbox has little benefit and is removed as well. This additionally
      fixes a bug that thumbnail preview rendering in file list module can't
      be turned off if the setup module checkbox is set.
      
      Additionally, the patch drops some unused css for the list module,
      'typo3-dblist' simply does not exist as class.
      
      Change-Id: If9365b5a26e708cc4d4d57cfcddd728cf97d7811
      Resolves: #92118
      Related: #79622
      Releases: master
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65493
      
      
      Tested-by: Achim Fritz's avatarAchim Fritz <af@achimfritz.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Daniel Windloff
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Achim Fritz's avatarAchim Fritz <af@achimfritz.de>
      Reviewed-by: Daniel Windloff
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      ae39eb5a
  19. 26 Aug, 2020 1 commit
  20. 27 Jul, 2020 1 commit
  21. 21 Jul, 2020 1 commit
    • Benni Mack's avatar
      [!!!][TASK] Remove lockToDomain feature for BE and FE · 0ce30f0a
      Benni Mack authored and Georg Ringer's avatar Georg Ringer committed
      Both fe_users/be_users and be_groups/fe_groups have a feature called "lockToDomain".
      
      Although it is called the same, it has a different use-case:
      
      * Users: If lockToDomain is set, the user is only allowed to login when a given HTTP_HOST is given.
      * Groups: If lockToDomain is set, the group is only added to the logged in user, if the HTTP_HOST matches this domain.
      
      Both features are rarely used, and even in multi-tenant setups not viable or flexible
      enough. In addition, the features are not any additional security measures as HTTP_HOST can be faked.
      
      They both add unneeded complexity for the rare use of a similar feature,
      a custom extension should be used.
      
      Plus: All of these features can be added via extensions, depending on a
      specific use case of an installation, so _if_ people use it, custom extensions
      should be used instead for the specific use case they have.
      
      The database fields, TCA definitions, labels, domain model logic in Extbase
      and actual validation within the AuthenticationService and BE_USER are removed
      without any substitution.
      
      Resolves: #91782
      Releases: master
      Change-Id: I4a12185b79efaf1e3bded5120675e3c1095dcd42
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65011
      
      
      Tested-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      0ce30f0a
  22. 29 Jun, 2020 1 commit
  23. 25 May, 2020 1 commit
  24. 20 Apr, 2020 1 commit
  25. 17 Apr, 2020 2 commits
  26. 16 Apr, 2020 1 commit
  27. 15 Apr, 2020 1 commit
  28. 14 Apr, 2020 2 commits
  29. 09 Apr, 2020 1 commit
  30. 22 Mar, 2020 1 commit
  31. 19 Mar, 2020 1 commit
  32. 06 Mar, 2020 2 commits
  33. 21 Feb, 2020 1 commit
  34. 19 Feb, 2020 1 commit
  35. 16 Feb, 2020 1 commit