Skip to content
  • Benni Mack's avatar
    [!!!][BUGFIX] Separate sys_history from sys_log db entries · d047b314
    Benni Mack authored
    Before, the history module fetched info about "modified records" from
    sys_history+the authoritive user from a coupled sys_log entry.
    
    Info about "insert" and "delete" was fetched from sys_log solely.
    
    However, when using a scheduled cleanup task to truncate sys_log
    then all history information is useless (see bug report).
    
    The patch introduces a new RecordHistoryStore as an abstraction
    for adding history entries (currently done solely within DataHandler).
    
    It adds some additional, necessary SQL fields to sys_history to
    store all information in there and creates an update wizard
    to migrate all coupled sys_history/sys_log entries to a
    new sys_history entry itself.
    
    Additionally, the whole existing "RecordHistory" class is
    now only necessary for fetching the so-called ChangeLog,
    for a page or a specific record, and to do rollbacks, preparing
    the history records so they can be worked on.
    
    The whole logic for fetching the GET/POST parameters is moved
    into the "ElementHistoryController", everything that is only possible
    via Fluid is moved from the RecordHistory object and the
    ElementHistoryController into the view.
    
    Referencing from sys_log (Log module) into sys_history is
    now done the other way around, storing information about
    the corresponding history entry inside sys_log.
    As a side-effect, sys_log should load faster.
    
    Abstraction basis:
    - sys_history is the only source of truth about the history of a record
    - sys_log contains a reference to an history entry now
    (inside sys_log.log_data) to link from the backend log module
    - RecordHistoryStore exists for tracking changes to records
    - RecordHistory is for retrieving, compiling the history/changelog and rollbacks
    - ElementHistoryController is doing PSR-7 style request/response
    handling and preparing data for the view
    - Fluid is handling more view functionality now, removing
    the need for doing <f:format.raw> everywhere in the templates.
    
    Sidenotes:
    * Data within sys_history is now stored as JSON, not serialized anymore
    * Adding/deleting was previously stored in sys_log only, is now within sys_history
    * Moving records is now tracked (but not evaluated yet)
    * Highlight/Snapshot functionality within the Backend Module
    was removed
    
    This functionality is built so it can also be used within Extbase
    persistence and in FE in general in a future iteration.
    
    Resolves: #55298
    Resolves: #71950
    Releases: master
    Change-Id: I354317609099bac10c264b9932e331fa908c98be
    Reviewed-on: https://review.typo3.org/53195
    
    
    Reviewed-by: default avatarAndreas Fernandez <typo3@scripting-base.de>
    Tested-by: default avatarAndreas Fernandez <typo3@scripting-base.de>
    Tested-by: default avatarTYPO3com <no-reply@typo3.com>
    Reviewed-by: default avatarJoerg Kummer <typo3@enobe.de>
    Tested-by: default avatarJoerg Kummer <typo3@enobe.de>
    Reviewed-by: default avatarBenni Mack <benni@typo3.org>
    Tested-by: default avatarBenni Mack <benni@typo3.org>
    d047b314