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