Patch #44274
open
Refactor Journal to decouple it from Issue
Description
Currently, Journal still contains several Issue-specific assumptions and behaviors.
This makes it difficult to reuse the journaling infrastructure for other models and requires Journal to know implementation details of Issue.
Following Holger Just's comment in #40890#note-2, Journal should act as a generic journal container and delegate model-specific behavior to the journalized object instead:
The refactoring should move Issue-specific logic out of Journal and provide a model-defined API for journalized records.
The current behavior for issues should remain unchanged.
Files
Updated by Florian Walchshofer about 19 hours ago
I've attached a patch that takes a first step towards decoupling Journal from Issue .
it introduces a new acts_as_journalized act which allows journalized models to provide their own Journal-related behavior.
Issue now registers itself using:
acts_as_journalized activity_type: 'issues'
The activity provider registration is optional and journalized models can participate in the journaling infrastructure without exposing activity events.
The patch also removes the remaining assumption that a Journal is always associated with an Issue.
In particular, the temporary belongs_to :issue association used for eager loading is no longer required and Journal relies on the polymorphic journalized association instead.
Visibility, activity and permission handling are delegated to the journalized model through the new API.
This includes model-specific joins and scopes used by Journal.visible , allowing each journalized model to define its own visibility requirements.
The patch focuses on behaviors currently implemented directly in Journal, including:
- activity provider registration and activity-specific scopes
- event title, event type and event URL generation
- journal visibility and private note visibility handling
- notification delivery
- watcher processing
- relation visibility checks
- editability checks
- project lookup and journalized record visibility
The current behavior for issues is preserved.
I intentionally did not try to generalize routes, controllers or other Issue-specific UI flows at this stage.
The goal of this patch is solely to decouple Journal from Issue and provide the necessary extension points for future journalized models.
I'm interested in feedback on whether this direction makes sense and could serve as a foundation for further Journal decoupling work.