[bug] Template.clean() corrections land one write late over the REST API

[asmodehn]

Describe the bug

ValidatedModelSerializer.validate() only applies incoming data when there is no
instance (creation); on PUT/PATCH it runs full_clean() on the instance as
loaded. So Template.clean() never sees the change being saved, and its
type-scoped corrections are applied one write late — the offending write stores
an inconsistent row, and some later unrelated write happens to fix it.

TemplateSerializer.validate_vpn does not catch this: it only fires when both
type and vpn are present in initial_data, so a type-only PATCH bypasses it.

Steps To Reproduce

1. Create a template with type="vpn" and a VPN attached.
2. PATCH /api/v1/controller/template/<pk>/ with
   {"type": "generic", "config": {"interfaces": []}} → 200.
3. Re-read the row: type is generic but vpn is still set, contradicting
   clean()'s "clears VPN specific fields if type is not VPN".
4. PATCH anything else, e.g. {"name": "renamed"} → only now is vpn set to
   None.

Same shape for required/default: PATCH {"required": true} stores
required=True, default=False, and default becomes True only on a later
write.

Expected behavior

The type change itself should clear vpn/auto_cert, and required should
force default on the same write.

Depends on openwisp/openwisp-utils#760 — and note that if that
lands as copy-based validation, Template.clean() will need to stop correcting
by assignment, since those corrections would no longer be saved at all.

Screenshots

N/A.

System Informatioon:

• OS: Pop!_OS 24.04 LTS
• Python Version: Python 3.13.5
• Django Version: Django 5.2.16
• Browser and Browser Version (if applicable): N/A (REST API)

Also: openwisp-controller 1.2.3, openwisp-utils 1.2.2, djangorestframework
3.16.1.

[krrishnaik]

Hi @asmodehn,

I’d like to work on this issue. I first checked both the OpenWISP Contributor's Board and the OpenWISP Priorities for next releases board for issue #1478, but I couldn't find it on either board.

I’ve gone through the reported behavior and the dependency on openwisp-utils#760, and I’m interested in investigating the issue and working on a fix. I’ve also set up the OpenWISP Controller development environment locally and verified that the relevant test setup is working.

Could you please validate the issue and add it to the appropriate OpenWISP project board so I can proceed with the contribution?

Thanks!

[mansiverma897993]

@nemesifier can you plz take a look on PR #1483 let me know the further changes if required !!