Previously, editing a custom link's text content created a spurious
URL_CHANGE row (fixed last commit) but no audit entry at all for the
actual content change. The product requirement: a change-log row SHOULD
be created so auditors see content was edited, but should NOT persist
the content itself.
LinkUpdateView now:
- Captures self.original_text in get_initial() alongside
self.original_url.
- After super().form_valid() writes the new text, compares old vs new
text. If different, creates a LinkChangeLog with
change_type=CONTENT_EDIT and metadata={'changed': True} — no content
payload. Applies to both LINK and CUSTOM link types.
- URL-change logging behaviour is unchanged.
Tests in TestCustomLinkEditUrlChangeLog now cover:
- custom link text edit creates CONTENT_EDIT, no URL_CHANGE
- custom link text unchanged creates no log
- regular link text change creates CONTENT_EDIT
- regular link URL change still logs URL_CHANGE
When editing a CUSTOM link's text content, the ViewUpdateView's
URL-change check was comparing the captured original_url (e.g.
'/custom/mynote') against form.cleaned_data['original_url'], which
for custom links is blank because the original_url input is hidden in
link_form.html and not submitted. They never matched, so every edit
produced a spurious LinkChangeLog 'URL changed' row.
Use the recomputed /custom/{alias} value (already set on
form.instance.original_url) for custom links, and only the submitted
form value for regular links. So the log now fires only when:
- a regular link's URL actually changes, or
- a custom link's alias changes (which derives a new /custom/{alias}).
Add TestCustomLinkEditUrlChangeLog covering:
- custom link text-edit produces no URL-change log
- regular link edit leaving URL unchanged produces no log
- regular link URL change logs once with old/new URL
- custom link alias change logs once with old/new derived URL
Select2 submits raw text as the value for new tags typed into the tag
box (tags: true + createTag in link_form.html). The previous
ModelMultipleChoiceField silently dropped those values because they
were not PKs of existing tags, so new tags were never persisted.
Add TagInputField, a tolerant ModelMultipleChoiceField subclass:
- existing tag PKs resolve as before
- raw text is treated as a new (or case-insensitive-existing) tag
- names are stripped and lowercased before get_or_create so the tag
namespace stays consistent and case-insensitive duplicates are
avoided. The Tag.save() hook still derives the slug.
LinkForm now uses TagInputField for its tags field, so both
LinkCreateView and LinkUpdateView pick up the new behaviour. The
Select2 createTag callback in link_form.html now lowercases the term
so users see immediately what will be stored.
Add 7 regression tests in TestLinkTagAutoCreate covering: new tag
created + lowercased; multiple new tags; existing tag reused (no
duplicate); mixed PK + new-text submission; no tags submitted; empty
or whitespace-only submission ignored; whitespace stripped.
Add integration tests covering the price-drop → Telegram alert flow:
- Sends Telegram MarkdownV2 message to global SiteSettings chat_id when
detected price <= watcher.alert_price_threshold.
- No alert when global creds missing.
- No alert when price above threshold.
- No alert when threshold unset on watcher.
- Non-recurring watcher with an undismissed alert is not re-notified.
- Telegram API failure does not break the check (snapshot + alert row
still persist, last_price updates).
AlertsPartialView (htmx-polled every 30s from the dashboard) returned
500 because _alerts.html used {% trans %} without {% load i18n %}.
Added the load tag so the partial renders correctly.
The dashboard's inline {% include 'pricemon/_alerts.html' %} also
relied on an undefined 'alerts' context var (DashboardView sets
'active_alerts'), so the alerts panel rendered empty even when alerts
existed. Pass alerts=active_alerts explicitly via the include.
Add regression tests covering both the dashboard render with an alert
and the alerts partial endpoint.
junv
github-actions[bot]
