2 of 2 people found this helpful
Create a custom form and store below values.
IP address, Support group ID(from CTM:Support Group form).
When you select any ip write action in SRD to fetch support group id from custom form.
Store support group id on hidden question and use that question to generate to approval for that group.
I know it is high level.
If ranges don't overlap, it might be better to expand Sidhdesh's suggestion a bit. Use three fields on custom form: start of range (source IP), end of range (destination IP) and approver(s); first two should be filled by submitter, the last one by SRD action which could look like this:
<Source IP> != $NULL$ AND
<Destination IP> != $NULL$
'Start of range' <= <Source> AND
'End of range' >= <Destination>
'Approver' ==> <Approver>
It is not really necessary to use numbers to represent addresses, simple text fields should do the trick as long as number of digits is constant (e.g. 002 instead of 2 so that it is evaluated as smaller then 160). If necessary, RegEx can be used to force submitter to enter them correctly.
Also, if it is easier for users to use zones, you could add that as fourth field in your custom form and instead of <Source IP> and <Destination IP> use query menu in SRD for zone selection and modified action for approver information retrieval.
i might use wrong explanation here but let me do it again
IP Range from 172.16.160.0 TO 172.16.167.254 IS Users ZONE
IP Range from 10.0.32.0 TO 10.0.33.254 IS APP ZONE
now the matrix like this that define the approver
destination zone port approver Users App XXX Security Group app Users YYY Hosting Group ... ... .. ... etc... etc... etc... etc...
the End user in SRD only Enters Source IP and Destination IP So i have to know the Source Zone and Destination Zone to determine the approver based on the above table
the problem i cant Compare the Source IP and destination IP in Which Zone
how to compare IP ?how can i say that the IP entered by the user is in 172.16.160.0 TO 172.16.167.254 for example ?
can i say in workflow if 172.16.164.10 > 172.16.160.0 and 172.16.164.10 < 172.16.167.254
That is why we asked you create custom form.
Store all the possible up address.
On srd create question query menu to fetch ip address from custom form so users have to select from menu itself rather than typing manually.
On srd action set group id on hidden question which you can use for approval.
1 of 1 people found this helpful
If I understand you correctly, submitter should enter source IP (which should determine source zone), destination IP (which should determine destination zone), and possibly port number as well, then source zone, destination zone, and port number should be used by SRD to determine approver.
Assuming that, you could use two custom forms -- they would only be used as look-up tables, so no special workflow is necessary in this context.
First custom form (your_custom_zoning_form) would define all zones using start of IP range, end of IP range and associated zone name; as long as all address fragments are expanded to three digits (e.g. 172.016.160.000 instead of 172.16.160.0), character fields can be used to store IP ranges. On SRD, you should add two "questions" which may but need not be hidden, but must be unchangable by submitter (so either hidden or read only) -- Source zone and Destination Zone. Then use actions like these to populate them:
Determine source zone
<Source IP> != $NULL$
'Start of range' <= <Source IP> AND
'End of range' >= <Source IP>
'Zone name' ==> <Source zone>
Determine destination zone
<Destination IP> != $NULL$
'Start of range' <= <Destination IP> AND
'End of range' >= <Destination IP>
'Zone name' ==> <Destination zone>
Second custom form (your_custom_zone_approver_form) should define relationships between source zone, destination zone, port number, and approver as in your matrix. SRD should look up approver value based on results of two previous actions using another action.
<Source zone> != $NULL$ AND
<Destination zone> != $NULL$
'Source zone' = <Source zone> AND
'Destination zone' = <Destination zone> AND
'Port number' = <Port number>
'Approver' ==> <Approver>
Use text as question format and /^[0-9][0-9][0-9]\.[0-9][0-9][0-9]\.[0-9][0-9][0-9]\.[0-9][0-9][0-9]$/ as RegEx for Source IP and Destination IP to force correct input (four groups of three-digit decimal numbers separated by dots), otherwise first two actions may not return correct zones.
Sidhdesh's suggestion to list all possible addresses in custom form and present those values via query menues would be fine if amount of addresses were small but it may be in (thousands of) thousands. On top of having to enter each address in your custom form (which could be automatized, but number of records couldn't be reduced either way), all of them would have to be shown in menu as well, and that wouldn't work without adjusting maximum number of choices or at all, and it certainly wouldn't be very user-friendly (e.g. in my expereience, not all submitters realize that they can refine search by typing in a part of desired choice, so they always scroll through all that's offered).
Thank you, seems working as expected
But I have question, why should I expand the address to three digits?
Without expanding the comparison is not working as expected
With expanding, it is working fine
How the comparison internally happens?
since values are stored as text both in SRD and custom form, they are later compared as text values so, for example,"11" < "2", but "11" > "02"; while first example is correct in context of string comparisons, the fact that numbers are stored as text isn't accounted for and the result is consequently incorrect in your context, thus values are zero-padded as in second example which is both correct in context of string comparisons and if text values are treatedd as numbers.
Internally, simple string comparison is used -- starting from first character in both strings, i-th characters are compared to each other until either characters differ (in this case result is of string comparison is the same as comparison of i-th characters), or the end of one string is reached (in that case the longer string is "bigger").