fortimgr_policy (incorrectly?) saves changes when param "lock" is false but a reference policy/direction and session set

[jcsicard]

Fortimgr_policy automatically saves changes even if parameter "lock" is set to false when a session id is provided.

This seems stem from a few instances of

            if module.params["session_id"]:
                self.save()

at lines 1677, 1724 and 1731 of fortimgr_policy.py, in the config_move function.

Is this the intended behaviour?

I'm also not sure what the purpose of saving the fmg workspace at those points is? Seems like it might be a API workaround to sync the FMG's state before looking up reference policy id/name. Is this right and if so actually/still required?

The behavior as it is right now messes up externally managed (through fortimgr_lock) workspace state. For example, when batch updating a policy package through a playbook, I want the whole FMG workspace to revert (unlock without save) if there is an error in a individual policy change.

JC

[davkap92]

Hi any updates here? @jcsicard , experiencing the same issue, behaviour seems inconsistent is this avoidable or a fortimanager design compliance necessity. thanks

[jcsicard]

I haven’t gotten around to revisiting this issue myself...

My guess is that the saves are un necessary development relics, but that would have to be tested out to see if they are somehow actually required for the add/move sequence to work...

AFAIK this should be pretty easy to test though, just comment out those if/save blocks and try it...