You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 20, 2024. It is now read-only.
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
The text was updated successfully, but these errors were encountered:
jcsicard
changed the title
fortimgr_policy (incorrectly?) saves changes when param "lock" is false but a session is passed
fortimgr_policy (incorrectly?) saves changes when param "lock" is false but a reference policy/direction and session set
Feb 11, 2020
Hi any updates here? @jcsicard , experiencing the same issue, behaviour seems inconsistent is this avoidable or a fortimanager design compliance necessity. thanks
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...
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
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
The text was updated successfully, but these errors were encountered: