Panorama 9.1.4. I'm sure this is a bug...
When a shared and device-group specific object with the same name exist, renaming the shared object updates references in the child device-group resulting in those objects (policies, profiles, address-groups, whatever) inheriting the shared object value instead of the DG-specific one. This should not happen - only references to the shared object should change.
Shared object: foo (184.108.40.206)
DG1 object: foo (220.127.116.11)
DG1 object: bar (18.104.22.168)
DG1 rule: foo (22.214.171.124) -> bar (126.96.36.199)
Renaming shared object "foo" to "foo-a" will result in the following:
DG1 rule: foo-a (188.8.131.52) -> bar (184.108.40.206)
If you rename the shared object to something else that exists in a child DG e.g. "bar":
DG1 rule: bar (220.127.116.11) -> bar (18.104.22.168)
Same applies to other object references - custom URL cats in URLF profiles, addresses in groups, profiles in profile groups etc.
The reason this should not happen is that any device-group specific object, if overriding a shared object, is there for a reason. No edits to the shared object should modify the child references IF an object with the same name exists in the child group.
TAC just pointed me to an article on how to override an ancestor object value in a child DG so I've asked them to replicate 🙂
It's a valid use case especially when importing multiple devices and those with objects in a vsys - for a customer with lots of firewalls you're bound to run into this issue.
Assuming you're in NZ, say hi to Mum for me!
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!