Support for uid

[randybb]

I know that uid's have been removed (for example https://github.com/CheckPointSW/CheckPointAnsibleMgmtCollection/issues/27), but we are using uid's for referencing rules - when we are updating/disabling/deleting existing one or adding new ones relative to existing rule defined by uid.

Existing rules have barely names (less than 0.01 %), but each rule has a comment (sometimes a custom variable with a tag) with a change number, so in case of rollback it can be used for finding related rules.

In our approval workflow are uid's mandatory and without uid support I must stick with my own scripts or just doing bare rest calls through ansible. Would be nice to switch to this collection.

Sure, in some cases it might be bad practice, but there can be a big warning, like Fortigate has in their collection when id 0 is used (still weir because in my scripts I can read new rule id from results, so pretty weird limitation).

Thanks

[chkp-dorbe]

Hi @randybb, As mentioned in the issue you referenced, using uid as a key for objects will damage the idempotency. Adding uid might have its merits as you described, but without idempotency, playbooks will not achieve their desired results, a case we want to avoid. Please don't hesitate to request other solutions or missing functionality. Regards, Dor.

[randybb]

Hi @chkp-dorbe, still think that idempotency is not a big deal thanks to sessions - if something raises an error I can drop the whole session. Doing exactly the same on Fortigates managed via FortiManager with enabled workspace mode (just locking ADOM for other people changes. Then the Workflow mode should be basically the same like sessions on CP).

If our checkpoint would be fully managed through automation, then this would not be a big deal. But people still catch them with their dirty hands, which is crazy for such simple tasks that can be easily automated.

For the other cases, like cleanup, is the UID the best - it is not changing over time, you can move rule up/down and everything is safe. And UID is by design uniq, where for example rule names or section names are not.

And there is another limitation when using object names - API is not case sensitive and in some situation, when people are doing mess (for example objects called ssh and SSH) cannot be selected other than by its UID.

A limitation about which you know is not always a limitation. I have a nice example from Fortigate, where they don't like when is id: 0 used in automation - if you are smart, you can simply create a rule/route with id 0, API will respond with the new ID which was assigned and then you can do whatever you want, for example move that ID behind other ID (yea, there is no position like on CP - you need to do the same thing in two API calls). Or I can just store that for a future use, or then just simply find all rules implemented withing a change (exact match, or through a reference in the description field,...).

Br, R>