chore(deps): update terraform unifi to v0.55.0 - #810
Open
amriksd[bot] wants to merge 1 commit into
Open
Conversation
amriksd
Bot
force-pushed
the
renovate/unifi-0.x
branch
from
July 6, 2026 14:27
8911adb to
bfc800c
Compare
amriksd
Bot
force-pushed
the
renovate/unifi-0.x
branch
from
July 11, 2026 11:53
bfc800c to
86f28fe
Compare
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.
This PR contains the following updates:
0.53.0→0.55.0Release Notes
ubiquiti-community/terraform-provider-unifi (unifi)
v0.55.0Compare Source
✨ Features
unifi_ap_group: manage AP group membership. Full CRUD, complementing the existing read-only data source. Which APs belong to a group was fixed in the controller UI: the data source could read a group, but nothing could create or edit one, sounifi_wlan.ap_group_idscould only reference groups built by hand. The resource writes membership through the v2apgroupsAPI.device_macsreuses theunifi_clientMAC type, soAA-BB-…andaa:bb:…read back equal rather than churning the plan on every refresh. Import takes the group ID, orsite:idfor a non-default site (#359, go-unifi#52).🐛 Bug Fixes
unifi_firewall_policy: fix creating a policy that matches an IP group failing withapi.err.EmptyFirewallDestinationIps(400). Asource/destinationreferencing an address group viaip_group_id(#316) must be sent withmatching_target_type = "OBJECT", but the #293 derivation back-filled an empty type asSPECIFICfor any non-ANY match — and on create the type is never controller-assigned, so every create withip_group_idwas rejected and only literalipsworked. A group reference now derivesOBJECT, also overriding a stale""/"ANY"/"SPECIFIC"carried in state so switching an existing policy from literalipsto a group reference works on update too; a controller-assignedOBJECT/LISTis still preserved (#365, #316, #293)unifi_device: carryswitch_vlan_enabled,radio_table[].vwire_enabled, andmesh_sta_vap_enabledin the update PUT. The update PUT was assembled from a minimalDevicethat dropped several configured fields, so the controller never received them and every apply that set one failed withinconsistent result after apply(was cty.True, but now cty.False). Fixed for:switch_vlan_enabled(the "Port VLAN" toggle, e.g. an AP with a built-in switch, where the toggle is what makes VLAN tagging take effect on the built-in ports);radio_table[].vwire_enabled(the "Mesh Parent" toggle — the wholeradio_tablewas omitted from the minimal PUT, dropping every radio sub-field); andmesh_sta_vap_enabled(the "Mesh Connect" toggle, newly added to theunifi_deviceschema as anOptional + Computedbool). All are now carried in the PUT body when configured.omitempty(at every level, includingradio_table) keeps afalse/empty off the wire, so it never disturbs the controller default. Verified against a real controller (#363)unifi_device/unifi_setting: stop controller-managed lists churning to "known after apply" on unrelated edits. SeveralOptional + Computedlists were replanned as(known after apply)whenever any other field on the same resource changed — a spurious diff (the same class as #338). They now useUseStateForUnknown, keeping their prior value unless explicitly changed:unifi_deviceradio_tableandoutlet_overrides, andunifi_settingcontents(syslog facilities),server_names(DoH),enabled_categories/enabled_networks(IPS), andnetwork_ids(IGMP snooping).unifi_ap_group: allow empty membership and stop empty groups reading back asnull.device_macswasRequiredwith aSizeAtLeast(1)validator, and the read mapped an empty member list toSetNull— so a group the controller legitimately allows to have zero members (the API returns 201 for an empty membership) could not be authored, and importing one surfaced as an empty-vs-nullinconsistency.device_macsnow accepts an empty set and reads empty back as an empty set. The built-in default "All APs" group (which the controller marks read-only) is documented as non-editable through the resource.v0.54.1Compare Source
🐛 Bug Fixes
unifi_radius_profile: makeauth_server/acct_serveripoptional so the default profile can be imported. The controller-managed default RADIUS profile (created when a gateway RADIUS/VPN service is enabled, withuse_usg_auth_server = true) returns a server entry without an IP.ipwasRequired, so re-declaring an imported profile failed withThe argument "ip" is required, and an empty IP read back as""instead of null.ipis nowOptionaland an absent IP maps to null, so the default profile round-trips cleanly (#356)v0.54.0Compare Source
✨ Features
unifi_network: expose the networkpurpose(corporate,guest,vlan-only). A newOptional + Computedattribute. The provider previously hard-codedcorporate(orvlan-onlyfor athird_party_gateway), so aguestnetwork could not be authored and a controller-assigned guest purpose was silently fought on every apply.purposeis now sent when configured and read back from the controller. Note: on Zone-Based-Firewall controllers the purpose is coupled to the firewall zone — aguestnetwork only keepspurpose = "guest"while it belongs to the guest/Hotspot zone (assign it there viaunifi_firewall_zone); placed in a non-guest zone the controller rewrites it back tocorporate.third_party_gateway = truestill forcesvlan-onlyfor backward compatibility (#276)unifi_firewall_policy: makeconnection_state_type/connection_statesauthor-settable. Both attributes wereComputed-only, so setting them returnedInvalid Configuration for Read-Only Attribute— you could not author a policy scoped to a specific connection state. They are nowOptional + Computed: leave them unset and the controller manages them as before, or setconnection_state_type = "CUSTOM"withconnection_states = ["NEW", …](orRESPOND_ONLY) to author, for example, aNEW-only logging/deny policy that coexists with stateful returns in a zone-based firewall. Values are validated (ALL/RESPOND_ONLY/CUSTOM; statesNEW/ESTABLISHED/RELATED/INVALID) and still round-trip on update (#351)unifi_wan: exposenetworkgroup(WAN,WAN2, …). A new computed-by-default attribute identifying which WAN group an interface belongs to. The provider previously hard-codedwan_networkgroup/attr_hidden_idtoWAN, so updating a secondary uplink (WAN2) collided with the primary and the controller rejected the PUT (api.err.WanConfigurationForNetworkGroupAlreadyExists). The group is now read from the controller and preserved in the update payload (UseStateForUnknown, so an importedWAN2needs no explicit config), making multi-WAN setups manageable (#334)🐛 Bug Fixes
unifi_network: fixinconsistent result after applyonmulticast_dnsfor non-vlan-only networks. Some controllers (notably UniFi OS gateways) ignore the per-networkmdns_enabledflag and always storefalse, so a configuredtrueconflicted with the post-apply read. The corporate-network read path now preserves the configured value (the vlan-only path already did), falling back to the controller's value only when it was left unset (#282)unifi_wan: fixinconsistent result after applyonwan_dslite_remote_host_auto. The controller can force this field back totrueserver-side, so the post-apply read conflicted with a user-configuredfalse. The create/update paths now re-assert the configured DS-Lite values on the post-apply state (the update path applied its write-preserve before the API round-trip, so the controller value won); the next refresh still reconciles with the controller (#281)unifi_firewall_policy: stopsource/destinationmatch lists churning to "known after apply" on unrelated edits. Changing any other field (e.g.indexorprotocol) replannednetwork_ids,client_macs,ipsandweb_domainsas(known after apply)— showing a spurious diff and risking the controller recomputing them. These Computed attributes now useUseStateForUnknown, so they keep their prior value unless explicitly changed (#338)unifi_device: fix LED updates failing withinconsistent result after apply. The update PUT body was assembled as a minimal device that dropped the LED override fields (led_override,led_override_color,led_override_color_brightness), so the controller kept the old values and the post-apply read conflicted with the plan. They are now included in the PUT, and — because the controller applies LED changes to APs asynchronously — the update path also re-asserts the planned LED values on the post-apply state, leaving the next refresh to reconcile with the controller (#337)unifi_device: fixmgmt_network_id(Network Override) never persisting. The update PUT was assembled from a minimalDevicethat dropped a configuredmgmt_network_id, so the controller never received it: every apply that set it failed withinconsistent result after apply, and the per-device management VLAN could not be set through the provider. The field is now carried in the PUT body when configured.omitemptykeeps a null value off the wire, so it never reintroduces the #177 zero-value rejection. The tag-upstream-first connectivity requirement documented in #330 still applies (#329)unifi_wan: fixinconsistent result after applyondnsaddress fields (primary,secondary,ipv6_primary,ipv6_secondary). When no DNS server is configured the controller persists and returns an empty string"", but these Optional fields plan asnull, so the post-apply read conflicted with the plan (e.g. after import with IPv6 DNS preferenceauto). The read now normalizes""(and a nil pointer) tonull, so unset addresses stay null and a real address still round-trips (#333)unifi_firewall_policy: makeindexread-only to stopinconsistent result after applyand a perpetual diff. Pinningindexfailed: the controller ignores a client-supplied value and always appends the policy at the end of its source/destination zone-pair, so the post-apply read (e.g.10010→10020) conflicted with the plan and then looped forever. Verified against a real UniFi OS 10.x controller — the supported integration API rejectsindexas input and exposes no reorder operation, so policy ordering cannot be managed through the provider.indexis nowComputed(controller-assigned) and the provider no longer sends it; reorder policies in the UniFi UI if needed (#348)Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate.