1. 12 Apr, 2021 1 commit
  2. 09 Mar, 2021 1 commit
  3. 16 Nov, 2020 3 commits
  4. 04 Nov, 2020 1 commit
    • Oliver Bartsch's avatar
      [TASK] Add new field for a list of compatible typo3 versions · fd4ebcdf
      Oliver Bartsch authored
      This adds a new field `compatible_typo3_versions` to the
      `tx_terfe2_domain_model_version` table to provide a list of
      compatible TYPO3 versions for each extension version.
      
      This information is needed in the database to allow simple SQL
      queries, e.g. used for the REST API `GET /extension` endpoint.
      
      The information is automatically added while uploading a new
      extension version. Furthermore, a one time migration symfony
      command is available to add this data to already existing records.
      fd4ebcdf
  5. 02 Nov, 2020 2 commits
    • Oliver Bartsch's avatar
      [TASK] Add new field for a list of compatible typo3 versions · 25200f66
      Oliver Bartsch authored
      This adds a new field `compatible_typo3_versions` to the
      `tx_terfe2_domain_model_version` table to provide a list of
      compatible TYPO3 versions for each extension version.
      
      This information is needed in the database to allow simple SQL
      queries, e.g. used for the REST API `GET /extension` endpoint.
      
      The information is automatically added while uploading a new
      extension version. Furthermore, a one time migration symfony
      command is available to add this data to already existing records.
      25200f66
    • Oliver Bartsch's avatar
      db9d8328
  6. 15 Oct, 2020 7 commits
  7. 10 Sep, 2020 1 commit
  8. 08 Sep, 2020 1 commit
  9. 17 Aug, 2020 1 commit
  10. 11 Aug, 2020 2 commits
  11. 07 Aug, 2020 4 commits
    • Thomas Löffler's avatar
      fe2c536a
    • Benni Mack's avatar
      [TASK] Migrate get.typo3.org cache file fetching into separate CLI command · b1e3460f
      Benni Mack authored
      The downloading of the current corejson file is happening in an
      outdated scheduler task, which is now needed anymore,
      as all jobs within the task are now handled through a CLI command, the
      latest being added is "ter:fetchCoreVersion".
      
      This way, the original "UpdateCurrentVersionListTask" can be removed,
      and in addition, the actual path of the cache file is now located in
      one single PHP class and encapsulated there.
      b1e3460f
    • Benni Mack's avatar
      [BUGFIX] Fix issues related to merging DB tables · 0bc0449c
      Benni Mack authored
      Two changes are needed since the unification of the database tables
      
      * When an extension version is uploaded or removed, the *_extension table
      needs an update (which was not the case before) with the current version
      information.
      For this reason the "ExtensionKey" API has a "UpdateExtensionInformation"
      method now, and some internal functions are moved to the ExtensionKey class
      
      * When an extension version (or extension) is deleted, Extbase attempted
      to also delete the information (which already happened in the TER)
      
      The SolR Re-Indexing is now placed at a more central point.
      0bc0449c
    • Benni Mack's avatar
      [TASK] Add Namespace to SOAP API handler class · c5a15264
      Benni Mack authored
      With the recent changes, the SOAP API is pretty much isolated and only
      called within one place now, so adding a proper PSR-4 namespace
      is finally possible with only a few minor changes.
      c5a15264
  12. 06 Aug, 2020 2 commits
    • Benni Mack's avatar
    • Benni Mack's avatar
      [!!!][TASK] Remove tx_ter_extensions & queue & importer task · ff3c42b3
      Benni Mack authored
      This change is the final change to remove any database tables
      from "EXT:ter", and remove any migration from TER v1 (SOAP) to
      TER v2 via a scheduler task.
      
      This change removes:
      * tx_ter_extensions (versions of an extension)
      * tx_ter_extensionqueue (+ its UploadQueue API object)
      * ImportExtensionsFromQueueTask (all migrated to ExtensionVersion for now)
      
      All DB rows are written directly into tx_terfe2_domain_model_version and
      its related tables.
      
      The API "ExtensionVersion->upload()" now produces everything necessary
      including notifications (which can be built via PSR-14 in the future).
      
      This also actually means that extensions are automatically available
      RIGHT AWAY after uploading an extension via the GUI or the SOAP API.
      
      Next Steps:
      * Refactor our upload API to make it more resistent and moving into a Event Sourcing concept (thinning out all underlying logic from ExtensionVersion again)
      * Refactor the permission concept and integrate it nicely
      * Remove dependencies to the SOAP API in EXT:ter_fe2
      ff3c42b3
  13. 04 Aug, 2020 1 commit
    • Benni Mack's avatar
      [TASK] Reduce usage to tx_ter_extensions · 99038b21
      Benni Mack authored
      This patch changes
      - the extensions.xml generator
      - various logic regarding checks if a version exists
      to not query the tx_ter_extensions database table anymore.
      
      Now the only place where tx_ter_extensions is actually used
      is the SOAP API Upload and the Migration to tx_terfe2_* db structure
      which will be migrated in the next patch.
      99038b21
  14. 01 Aug, 2020 1 commit
    • Benni Mack's avatar
      [TASK] Add additional fields to version table for TER v1 migration · 8d64a717
      Benni Mack authored
      Four new fields are added to the tx_terfe2_domain_model_version table,
      which are migrated through a one-time-command "ter:migratedetailstov2"
      from TER v1 tables, and updated on TER v1 Upload as well.
      
      These fields are available in a normalized way, but are also needed
      flat for the extensions.xml.gz file, which makes the SQL query for building
      the XML faster in the future (next update), and allows for dropping the
      tx_ter_extensions table in the next iteration.
      
      The fields are currently not added to TCA as they serve no purpose
      (yet) for the frontend as it is up to decide if we keep the "*_authors" table
      or keep the extension version information in the main *_version table.
      8d64a717
  15. 23 Jul, 2020 1 commit
    • Benni Mack's avatar
      [TASK] Move extension upload out of SOAP API · 84c3d7de
      Benni Mack authored
      The actual logic for uploading a new TER extension version
      is moved into the ExtensionVersion->upload() method,
      which handles all checks.
      
      This way, the tx_ter_api is not needed anymore outside
      the SOAP API (except for TerService, which will be adapted
      separately to work without tx_ter_api).
      84c3d7de
  16. 21 Jul, 2020 1 commit
    • Benni Mack's avatar
      [!!!][TASK] Drop usage of tx_ter_extensionkeys · e5ee1dcd
      Benni Mack authored
      The database table tx_ter_extensionkeys containing all registered
      extensionkeys is dropped in favor of "tx_terfe2_domain_model_extension".
      
      This table was synced already anyways, and can now be used within extensions.typo3.org
      without having to sync with a cronjob anymore.
      
      Breaking: The information about "title" and "description" is removed, as it wasn't
      required via the Web GUI when registering a key already.
      
      The sync task / TER importer now only imports the uploaded versions, the SOAP API
      now creates records directly in tx_terfe2_domain_model_extension when
      registering a new extension key.
      
      The One-Time-Migration-Script by tomalo (ImportAllExtensionKeysTask) is
      now removed as it is not needed anymore.
      e5ee1dcd
  17. 15 Jul, 2020 1 commit
  18. 14 Jul, 2020 5 commits
  19. 13 Jul, 2020 2 commits
    • Benni Mack's avatar
      [BUGFIX] CGL cleanups · 8d3b85d1
      Benni Mack authored
      8d3b85d1
    • Benni Mack's avatar
      [FEATURE] Add ExtensionVersion API · 62fe2acc
      Benni Mack authored
      A new API class "ExtensionVersion" deals with a specific uploaded
      version of an extension.
      
      This class is responsible for checking sanitized versions, and serves
      as entrypoint to hide the logic behind "tx_ter_extensions" (and soon "tx_ter_extensiondetails"), by also handling deletion, updating reviewstate
      or uploading of new extension versions.
      
      On top, all TYPO3_DB calls are removed from EXT:ter with this change, moving
      more actual logic out of the SOAP API endpoints.
      
      In addition, the non-SOAP-API is now using non-static calls, as all
      logic is wrapped in a doUpload() method.
      62fe2acc
  20. 09 Jul, 2020 2 commits
    • Benni Mack's avatar
      [FEATURE] Encapsulate "tx_ter_extensionkeys" access · 450ec6ae
      Benni Mack authored
      A new object "ExtensionKey" now allows to work with Extension Keys
      in the SOAP API with an object-oriented approach.
      
      This heavily reduces the tx_ter_helper class and removes helper
      functionality from tx_ter_api.
      
      The new ApiUser is now used to validate requests that need a valid
      user (registering an API key, or transferring ownership) as argument.
      450ec6ae
    • Benni Mack's avatar
      [TASK] Migrate authentication logic into ApiUser class · 0b8aac4c
      Benni Mack authored
      This change adds an object called "ApiUser" which can be built with
      a factory method "createFromSoapAccountData".
      
      Using the ApiUser allows for easy access of the user data, and
      covers both TSFE and LDAP dependencies which can later be exchanged
      easily for other purposes via a possible ApiUserInterface.
      
      The helper class usages are now reduced to continue removing
      legacy code and TYPO3_DB calls.
      0b8aac4c