sentry-jaga 1.0.0__tar.gz

sentry_jaga-1.0.0/.gitignore

@@ -0,0 +1,363 @@
+### JetBrains template
+# Covers JetBrains IDEs: IntelliJ, RubyMine, PhpStorm, AppCode, PyCharm, CLion, Android Studio, WebStorm and Rider
+# Reference: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839
+
+# User-specific stuff
+.idea/**/workspace.xml
+.idea/**/tasks.xml
+.idea/**/usage.statistics.xml
+.idea/**/dictionaries
+.idea/**/shelf
+
+# AWS User-specific
+.idea/**/aws.xml
+
+# Generated files
+.idea/**/contentModel.xml
+
+# Sensitive or high-churn files
+.idea/**/dataSources/
+.idea/**/dataSources.ids
+.idea/**/dataSources.local.xml
+.idea/**/sqlDataSources.xml
+.idea/**/dynamic.xml
+.idea/**/uiDesigner.xml
+.idea/**/dbnavigator.xml
+
+# Gradle
+.idea/**/gradle.xml
+.idea/**/libraries
+
+# Gradle and Maven with auto-import
+# When using Gradle or Maven with auto-import, you should exclude module files,
+# since they will be recreated, and may cause churn.  Uncomment if using
+# auto-import.
+# .idea/artifacts
+# .idea/compiler.xml
+# .idea/jarRepositories.xml
+# .idea/modules.xml
+# .idea/*.iml
+# .idea/modules
+# *.iml
+# *.ipr
+
+# CMake
+cmake-build-*/
+
+# Mongo Explorer plugin
+.idea/**/mongoSettings.xml
+
+# File-based project format
+*.iws
+
+# IntelliJ
+out/
+
+# mpeltonen/sbt-idea plugin
+.idea_modules/
+
+# JIRA plugin
+atlassian-ide-plugin.xml
+
+# Cursive Clojure plugin
+.idea/replstate.xml
+
+# SonarLint plugin
+.idea/sonarlint/
+
+# Crashlytics plugin (for Android Studio and IntelliJ)
+com_crashlytics_export_strings.xml
+crashlytics.properties
+crashlytics-build.properties
+fabric.properties
+
+# Editor-based Rest Client
+.idea/httpRequests
+
+# Android studio 3.1+ serialized cache file
+.idea/caches/build_file_checksums.ser
+
+### VirtualEnv template
+# Virtualenv
+# http://iamzed.com/2009/05/07/a-primer-on-virtualenv/
+.Python
+[Bb]in
+[Ii]nclude
+[Ll]ib
+[Ll]ib64
+[Ll]ocal
+[Ss]cripts
+# ...but not our own scripts/ directory (the pattern above targets Windows venvs).
+!/scripts/
+
+# Planning artefacts, not documentation: they describe what was intended, not what was built.
+/docs/superpowers/
+
+# The release runbook is the maintainer's own note, not part of the published project.
+/docs/release.md
+
+# Editor and rebase leftovers. The wheel target ships everything under `src/sentry_jaga`, so a
+# `.bak` next to a module would be published to PyPI inside it.
+*.bak
+*.mbak
+*.orig
+*.rej
+
+# Throwaway probe scripts: they talk to a real Jaga instance with real credentials. What they found
+# lives in the docstrings of the code they justify (`JagaClient.transition_task`, `attach_file`,
+# `get_or_create_label`, `fields.injected_attributes`). Keep yours locally.
+/scripts/probe_*.py
+pyvenv.cfg
+.venv
+pip-selfcheck.json
+
+### Linux template
+*~
+
+# temporary files which can be created if a process still has a handle open of a deleted file
+.fuse_hidden*
+
+# KDE directory preferences
+.directory
+
+# Linux trash folder which might appear on any partition or disk
+.Trash-*
+
+# .nfs files are created when an open file is removed but is still being accessed
+.nfs*
+
+### Windows template
+# Windows thumbnail cache files
+Thumbs.db
+Thumbs.db:encryptable
+ehthumbs.db
+ehthumbs_vista.db
+
+# Dump file
+*.stackdump
+
+# Folder config file
+[Dd]esktop.ini
+
+# Recycle Bin used on file shares
+$RECYCLE.BIN/
+
+# Windows Installer files
+*.cab
+*.msi
+*.msix
+*.msm
+*.msp
+
+# Windows shortcuts
+*.lnk
+
+### macOS template
+# General
+.DS_Store
+.AppleDouble
+.LSOverride
+
+# Icon must end with two \r
+Icon
+
+# Thumbnails
+._*
+
+# Files that might appear in the root of a volume
+.DocumentRevisions-V100
+.fseventsd
+.Spotlight-V100
+.TemporaryItems
+.Trashes
+.VolumeIcon.icns
+.com.apple.timemachine.donotpresent
+
+# Directories potentially created on remote AFP share
+.AppleDB
+.AppleDesktop
+Network Trash Folder
+Temporary Items
+.apdisk
+
+### Python template
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#pdm.lock
+#   pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
+#   in version control.
+#   https://pdm.fming.dev/latest/usage/project/#working-with-version-control
+.pdm.toml
+.pdm-python
+.pdm-build/
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#  and can be added to the global gitignore or merged into this file.  For a more nuclear
+#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
+#.idea/
+
+# ruff
+.ruff_cache/
+
+
+### Project
+# IDE clutter (the template above only covers it partially — cover it entirely)
+.idea/
+
+# The internal Jaga API spec (Rostelecom): it goes neither into the OSS repo nor a release
+jaga-openapi.json
+
+# Scratch space of the SDD agents
+.superpowers/
+
+# Sentry sources used for type checking (cloned locally / in CI)
+.sentry-src/
+
+# Scratch worktrees of subagents
+.claude/

sentry_jaga-1.0.0/.pre-commit-config.yaml

@@ -0,0 +1,15 @@
+repos:
+  - repo: https://github.com/astral-sh/ruff-pre-commit
+    rev: v0.6.9
+    hooks:
+      - id: ruff
+        args: [--fix]
+      - id: ruff-format
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.6.0
+    hooks:
+      - id: end-of-file-fixer
+      - id: trailing-whitespace
+      - id: check-toml
+      - id: check-yaml
+      - id: check-merge-conflict

sentry_jaga-1.0.0/CHANGELOG.md

@@ -0,0 +1,100 @@
+# Changelog
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/).
+
+## [Unreleased]
+
+## [1.0.0] - 2026-07-14
+
+The first public release. Everything below was verified against a live Jaga instance and a real
+self-hosted Sentry 26.3.1, not against the API spec, which turned out to be wrong about six separate
+things.
+
+### Fixed
+
+- **The "Assignees" select was always empty, and said nothing about it.** It was filled from the
+  endpoint the spec documents for exactly this — `GET /v1/project/getUserProfileDtos/{projectId}` —
+  which on a live instance answers `200 []` for *every* space, including one the asking account
+  owns. It does not fail; it silently reports that nobody is there.
+
+  The members now come from the space's user-role matrix
+  (`GET /v1/team/userRoles/applications/JAGA/projects/{projectId}`). `applicationMnemo` is a required
+  path segment the spec never gives a value for; `JAGA` is the one a live instance accepts. The old
+  endpoint is kept only as a fallback for when the matrix itself errors — an *empty* matrix is taken
+  at face value, since a space really can have no members.
+
+### Added
+
+- **Assignee sync (`Sync assignment to Jaga`, off by default).** Assigning a Sentry issue puts the
+  person on the linked Jaga task; unassigning takes them off. Matched by email — the user's primary
+  address first, then their verified ones. A Sentry user Jaga has never heard of leaves the task
+  exactly as it was, and is never turned into an unassignment. Assigning an issue to a Sentry
+  **team** does nothing in Jaga. Off by default because it names a real person in another system.
+
+  The assignee turned out **not** to be the "task role" the spec advertises: the documented
+  `PUT /v1/taskRole/task/{taskId}/executor` does not exist on a live instance (404, `No static
+  resource ...`). It is an ordinary EAV attribute, written with `PATCH /v1/task/{taskId}`, and
+  writing it fills the task's `executors` — the attribute *is* what Jaga's UI calls the executor.
+- **Linking searches every space at once** (`POST /v1/globalSearch/findTaskList`). Jaga's per-space
+  search demands a `projectId`, which is why the link form used to make you pick a space first.
+- **The Sentry event can be attached to the task** as a JSON file (`Attach the Sentry event to the
+  task`, **off by default**). It is the event as `Event.as_dict()` serves it, so it carries personal
+  data — the user's email, request headers and body — which is why an admin has to turn it on
+  deliberately. A failed upload is logged and swallowed: the task is already created by then.
+
+  The attachment is run through **Sentry's own data scrubber**
+  (`sentry.relay.datascrubbing.scrub_data`) before it is uploaded, so it honours every privacy
+  setting of the project and the organization: IP scrubbing, additional sensitive fields, the default
+  rules, and the advanced PII rules. Because the rules are applied to the *stored* event rather than
+  on ingest, this is stricter than Sentry's own "JSON" view. A scrub that fails means no attachment
+  at all — never an unscrubbed one.
+
+  It does **not** apply to tasks filed by an alert rule: the rule modal renders the create form with
+  no issue behind it and saves the result into the rule, so the hidden field that carries the issue
+  is not emitted there — otherwise one frozen group id would attach the event of a single long-dead
+  issue to every task the rule ever filed.
+- **Every task created from Sentry is labelled** (`sentry` by default, configurable per
+  organization; an empty setting turns it off). The label is created on first use
+  (`POST /v1/labels/list` is a get-or-create) and is *added* to the labels picked in the create form
+  rather than replacing them. A task type without a label attribute is filed without a label.
+- The status sync now **moves the linked Jaga task**, instead of only commenting on it. The target is
+  configured per organization as a status *category* (Done / In progress / To do), and the concrete
+  status is resolved per task from the ones its own workflow can reach — Jaga keeps a separate copy
+  of every status per workflow (~90k of them on a real instance), so a status id cannot be mapped
+  directly.
+- Organization settings for the sync: the categories to move the task to when an issue is resolved
+  and when it regresses, and whether to comment in addition to moving.
+- **The create form remembers the space and task type** last filed into, per Sentry project. A
+  remembered space that Jaga no longer offers the service account falls back to the first available
+  one instead of breaking the form.
+- **Sentry notes can be synced to Jaga as comments** (`Sync Sentry comments to Jaga`, **off by
+  default**). A note is posted as `<Author> wrote:` followed by its quoted text, and editing the note
+  rewrites the comment it created rather than adding a second one. Off by default because a Sentry
+  note is internal discussion and the Jaga task may have a wider audience.
+- **Linking an existing task now comments on it**, with a link back to the Sentry issue. The text is
+  pre-filled in the link form and is editable: clearing the box posts nothing, which is why this
+  needs no organization-wide setting.
+
+### Changed
+
+- **The link form no longer asks for a space** (the search is global now), and its suggestions read
+  `code — title`: the global search returns a found task's space as `null`, and fetching it per
+  suggestion, per keystroke, is not worth the round trips. The search endpoint
+  (`/extensions/jaga/search/…`) no longer takes a `project` parameter.
+- The project is now fully in English: documentation, code comments and user-facing strings.
+- The tests of the Sentry layer now run against a real Sentry 26.3.1, in Sentry's own environment
+  (see CONTRIBUTING.md). The `sentry` dependency group is gone: it could never have worked, as Sentry
+  is not installable as a package.
+
+### The rest of what 1.0.0 contains
+
+- Creating Jaga tasks from a Sentry issue, with the attributes of the chosen task type rendered
+  dynamically (Jaga's EAV model).
+- Linking an existing Jaga task to a Sentry issue.
+- Installation through a form: the Jaga URL plus a service account, with the credentials checked
+  before the integration is created.
+- Ticket Rules: an alert rule can file a Jaga task by itself.
+
+[Unreleased]: https://github.com/happykust/sentry-jaga/compare/v1.0.0...HEAD
+[1.0.0]: https://github.com/happykust/sentry-jaga/releases/tag/v1.0.0

sentry_jaga-1.0.0/CODE_OF_CONDUCT.md

@@ -0,0 +1,130 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, caste, color, religion, or sexual
+identity and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+- Demonstrating empathy and kindness toward other people.
+- Being respectful of differing opinions, viewpoints, and experiences.
+- Giving and gracefully accepting constructive feedback.
+- Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience.
+- Focusing on what is best not just for us as individuals, but for the overall
+  community.
+
+Examples of unacceptable behavior include:
+
+- The use of sexualized language or imagery, and sexual attention or advances of
+  any kind.
+- Trolling, insulting or derogatory comments, and personal or political attacks.
+- Public or private harassment.
+- Publishing others' private information, such as a physical or email address,
+  without their explicit permission.
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting.
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official email address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at
+**me@happykust.dev**.
+
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series of
+actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or permanent
+ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior, harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within the
+community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.1, available at
+https://www.contributor-covenant.org/version/2/1/code_of_conduct.html.
+
+Community Impact Guidelines were inspired by
+[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
+
+[homepage]: https://www.contributor-covenant.org
+[Mozilla CoC]: https://github.com/mozilla/diversity
+
+For answers to common questions about this code of conduct, see the FAQ at
+https://www.contributor-covenant.org/faq. Translations are available at
+https://www.contributor-covenant.org/translations.