You are reading an unmaintained version of the Ansible documentation. Unmaintained Ansible versions can contain unfixed security vulnerabilities (CVE). Please upgrade to a maintained version. See the latest Ansible documentation.

fortinet.fortimanager.fmgr_dvmdb_workspace_commit_obj – Commit change

Note

This plugin is part of the fortinet.fortimanager collection (version 2.1.4).

You might already have this collection installed if you are using the ansible package. It is not included in ansible-core. To check whether it is installed, run ansible-galaxy collection list.

To install it, use: ansible-galaxy collection install fortinet.fortimanager.

To use it in a playbook, specify: fortinet.fortimanager.fmgr_dvmdb_workspace_commit_obj.

New in version 2.10: of fortinet.fortimanager

Synopsis

• This module is able to configure a FortiManager device.

• Examples include all parameters and values which need to be adjusted to data sources before usage.

Parameters

Parameter	Comments
adom string / required	the parameter (adom) in requested url
bypass_validation boolean	only set to True when module schema diffs with FortiManager API structure, module continues to execute without validating parameters Choices: no ← (default) yes
enable_log boolean	Enable/Disable logging for task Choices: no ← (default) yes
object_url_name string / required	the parameter (object_url_name) in requested url
rc_failed list / elements=string	the rc codes list with which the conditions to fail will be overriden
rc_succeeded list / elements=string	the rc codes list with which the conditions to succeed will be overriden
workspace_locking_adom string	the adom to lock for FortiManager running in workspace mode, the value can be global and others including root
workspace_locking_timeout integer	the maximum time in seconds to wait for other user to release the workspace lock Default: 300

Notes

Note

• Running in workspace locking mode is supported in this FortiManager module, the top level parameters workspace_locking_adom and workspace_locking_timeout help do the work.

• To create or update an object, use state present directive.

• To delete an object, use state absent directive.

• Normally, running one module can fail when a non-zero rc is returned. you can also override the conditions to fail or succeed with parameters rc_failed and rc_succeeded

Examples

- hosts: fortimanager-inventory
  collections:
    - fortinet.fortimanager
  connection: httpapi
  vars:
     ansible_httpapi_use_ssl: True
     ansible_httpapi_validate_certs: False
     ansible_httpapi_port: 443
  tasks:
   - name: Commit change
     fmgr_dvmdb_workspace_commit_obj:
        bypass_validation: False
        workspace_locking_adom: <value in [global, custom adom including root]>
        workspace_locking_timeout: 300
        rc_succeeded: [0, -2, -3, ...]
        rc_failed: [-2, -3, ...]
        adom: <your own value>
        object_url_name: <your own value>

Return Values

Common return values are documented here, the following are the fields unique to this module:

Key	Description
request_url string	The full url requested Returned: always Sample: “/sys/login/user”
response_code integer	The status of api request Returned: always Sample: 0
response_message string	The descriptive message of the api response Returned: always Sample: “OK.”

Authors

• Link Zheng (@chillancezen)

• Jie Xue (@JieX19)

• Frank Shen (@fshen01)

• Hongbin Lu (@fgtdev-hblu)