Repository navigation
Conversation
# Conflicts: # db/structure.sql
The fulltext_search method was vulnerable to SQL injection via apostrophes and other special characters in user input that break PostgreSQL tsquery syntax (e.g., ' dunaji'123 ' causes PG::SyntaxError). Changes: - Add DISALLOWED_TSQUERY_CHARACTERS regex to filter out dangerous chars - Extract sanitize_terms method for better testability and readability - Sanitize query by replacing ' ? \ : with spaces before splitting - Return empty scope (none) if all terms are sanitized away - Add comprehensive tests for both fulltext_search and sanitize_terms - Add Brakeman ignore for false positive SQL injection warning (against/unaccent_f are controlled by developer, not user input) Fixes: ERROR: syntax error in tsquery: "' dunaji'123 '"
Make jobs communicating with Zammad idempotent, able to recover from previous uncompleted runs without failing again closes #42
Otherwise it crashes if env variables are not set
If somebody starts their local .env from .env.sample, they need this env variable to be `present?`. If it's blank here, local mail delivery does not work.
Member
Author
Prípadne ešte môžeme pri RS change spraviť špeciálny prípad kedy sa priradí RS, resp. keď nikto ešte nebol priradený. |
Member
|
@xhyrom tu este mozno otazka, ze ci je nejako aspon ciastocne mozne spatne zrekonstruovat historiu pre podnety? |
Member
|
Toto je dobry screen, ale nadpis "Diskusia" uz asi nedava uplne zmysel. |
Member
Author
áno, vedeli by sme to všetko spätne získať z triáže, keďže zammad ukladá históriu všetkých zmien fieldov. |
jsuchal
reviewed
Oct 12, 2026
Collaborator
|
@xhyrom v |
jsuchal
requested changes
Oct 14, 2026
1 task done
mirrec
changed the title
PublishIssueResponsibleSubjectChangedJob called ResponsibleSubject.find(nil) when an issue got its first responsible subject (nil -> X), e.g. from the Triage 700 trigger, and failed. A nil previous subject is now handled explicitly, an unknown id still fails the job.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
Closes #36
Refs https://github.com/slovensko-digital/ops/issues/1181
When an operator changes an issue's state or its responsible subject (RS) in Triage, nothing shows up on the portal unless they also write a comment. Often the RS is quietly switched to "Iný subjekt", and to the author and subscribers the issue looks abandoned. The change history is visible in Triage, but not to the people who reported or follow the issue. Subscribers also get no email when an issue goes in progress or moves to a different RS.
Solution
State changes and RS changes are now recorded as activities in the issue's timeline, next to comments and updates. The section heading changes from Diskusia to Aktivita.
Issues::StateChangeActivity→Issues::StateChangeandIssues::SystemResponsibleSubjectChangeActivity→Issues::SystemResponsibleSubjectChange, are created byafter_updatecallbacks inapp/models/issue.rbwheneverstate_idorresponsible_subject_idchanges, no matter what triggered the change. Both returntriage_visible? == false, so they are never synced back to Triage (Triage already keeps its own history).issues/state_changes/_state_changeandissues/system_responsible_subject_changes/_system_responsible_subject_changeshow a compact "previous → new" row with state badges. A missing previous value appears as neznámy stav / neznámy.issue_in_progressemail goes out fromPublishIssueStateChangedJob. A newPublishIssueResponsibleSubjectChangedJobsendsissue_responsible_subject_changedto active, email-notifiable subscribers. The RS email is only sent when the state did not change in the same update, because the state-change notification takes priority.Triage::BackfillIssueHistoryJobrebuilds both histories for existing issues from Zammad'sticket_historyendpoint (newZammadApiClient#get_ticket_history). It reads both the triage and resolution tickets, mapsops_stateandresponsible_subjectvalues to portal records, and inserts the entries in bulk with their original timestamps. It does nothing for an issue that already has activities of a given type. When the latest Zammad value differs from the current portal value, it logs this and imports the Zammad history as is.Deliberately out of scope: other edits to an issue (title, description, category) are not tracked yet.
Verify: run
bin/rails test test/lib/zammad_api_client_test.rb test/jobs/notifications test/jobs/triage/backfill_issue_history_job_test.rb, then change an issue's state and RS (e.g. in the console) and open its detail page.Demo
Checklist
docs/how-it-works/is updated, or this PR changes no flow (job, webhook, Triage or Backoffice trigger, issue state, email, scheduled job)