Check the upstream zammad/zammad repository for changes that could break or require updates to our Zammad addon (`packages/zammad-addon-link`).
## Arguments
-`$ARGUMENTS` - Optional: target Zammad version/tag/branch to compare against (e.g. `6.6.0`, `stable`). If not provided, ask the user what version to compare against. The current version is in `docker/zammad/Dockerfile` as the `ZAMMAD_VERSION` ARG.
## Setup
1. Read the current Zammad version from `docker/zammad/Dockerfile` (the `ARG ZAMMAD_VERSION=` line).
2. Clone or update the upstream Zammad repository:
- If `/tmp/zammad-upstream` does not exist, clone it: `git clone --bare https://github.com/zammad/zammad.git /tmp/zammad-upstream`
- If it exists, update it: `git -C /tmp/zammad-upstream fetch --all --tags`
3. Determine the version range. The current version is the `ZAMMAD_VERSION` from step 1. The target version is the argument or user-provided version. Both versions should be used as git refs (tags are typically in the format `X.Y.Z`).
## Checks to Perform
Run ALL of these checks and compile results into a single report.
### 1. Replaced Stock Files
These are stock Zammad files that our addon REPLACES with modified copies. Changes upstream mean we need to port those changes into our modified versions.
For each file below, diff the upstream version between the current and target version. Report any changes found.
If a file does not exist at either version, note that (it may have been added, removed, or renamed).
### 2. Monkey-Patched Files
These are files our addon patches at runtime via Ruby `prepend`, `include`, or `after_initialize` hooks. Changes to these files could break our patches.
-`lib/search_index_backend.rb` - We prepend `SearchIndexBackendOpenSearchPatch` to override `_mapping_item_type_es`. Check if this method signature or the `'flattened'` string usage has changed.
**Core Models (callback injection targets):**
-`app/models/ticket/article.rb` - We inject `after_create` callbacks via `include` for Signal and WhatsApp message delivery. Check for changes to the callback chain, model structure, or the `Sender`/`Type` lookup patterns.
-`app/models/link.rb` - We inject an `after_create` callback for Signal group setup on ticket split. Check for structural changes.
**Transaction System:**
-`app/models/transaction/` directory - We register `Transaction::SignalNotification` as backend `0105_signal_notification`. Check if the transaction backend system has been refactored.
**Icons:**
-`public/assets/images/icons.svg` - Our initializers append SVG icons at boot time. Check if the SVG structure or the icon injection mechanism has changed.
For the search backend specifically, also check if `_mapping_item_type_es` still exists and still returns `'flattened'`:
```bash
git -C /tmp/zammad-upstream show <target-version>:lib/search_index_backend.rb | grep -n -A5 '_mapping_item_type_es\|flattened'
```
### 3. API Surface Dependencies
These are Zammad APIs/interfaces/mixins our addon relies on. Changes could cause runtime failures.
**Channel Driver Interface:**
-`app/models/channel/driver/` - Check if the driver base class or interface expectations have changed (methods: `fetchable?`, `disconnect`, `deliver`, `streamable?`).
**Controller Concerns:**
-`app/controllers/concerns/creates_ticket_articles.rb` - Used by our webhook controllers. Check for interface changes.
**Ticket Article Types & Senders:**
-`app/models/ticket/article/type.rb` and `app/models/ticket/article/sender.rb` - We look up types by name (`'signal message'`, `'whatsapp message'`). Check for changes in how types are registered or looked up.
**Authentication/Authorization:**
-`app/policies/` directory structure - We create policies matching `controllers/` names. Check if the policy naming convention or base class has changed.
**Package System:**
-`lib/package.rb` or the package install/uninstall API - We use `Package.install(file:)` and `Package.uninstall(name:, version:)` in setup.rb.
**Scheduler/Job System:**
-`app/jobs/` base class patterns - Our jobs inherit from ApplicationJob. Check for changes.