Hi Ben,
Sorry but I disagree and still think it's counter-intuitive. The response data is an echo of the information you have just used to create the incident plus some additional information (being the most important to me the incident ID, which cannot be known in advance). As the incident ID is needed to update an incident, this makes pointless the segmentation of the "edit" and "read" privileges when I want to create an incident and immediately update it. If this is still the logic that IBM believes makes sense, then the /incidents endpoint should get updated to echo back at least just the incident ID.
I would not have expected to need "edit org data" to create an incident. -> Me neither, hence my need for documentation. I believe I tested this already using only the API, which lead me to this confusion. I could try again, but would mean more time invested from my side trying to infer the inner design of these permissions and would have to try all possible combinations to clarify some strange circumstances like the one described in my first paragraph.
Thanks again for your support.
------------------------------
Regards,
Carlos Ortigoza
------------------------------
Original Message:
Sent: Tue March 10, 2020 11:47 AM
From: Ben Lurie
Subject: API keys permissions details
It definitely is the case that just because an incident can be created (create incident perm) that the response data (the incident data) would not be sent if there is no read permission. There are lots of ways the system can be configured such that the person/api key that created an incident cannot view it (think workspaces, etc). So if you need to see the incident data, including the id, you'll need to give read incident permission.
I would not have expected to need "edit org data" to create an incident. Are you using resilient circuits? That may be a requirement of resilient circuits. But I think you can test it out independently of circuits and see that it is possible to create/read incidents independent of "edit org data".
Ben
------------------------------
Ben Lurie
Original Message:
Sent: Tue March 10, 2020 10:10 AM
From: Carlos Ortigoza
Subject: API keys permissions details
Hi Ben,
Cool, thanks! The first question I have is if it makes sense that not providing "Read Incident" permission does not even allow to read the echo response you get when you create an incident in Resilient. We have a problem because I want to create an incident, get the resulting incident ID and then use it to edit the incident and add an attachment or anything we need. However, due to this counter intuitive configuration, granting "Incident Create" permission and all permissions under "Edit Incidents" does not work.
Also, I found that even for this pretty specific example described above, I was forced to grant "Edit Org Data" permission although this is clearly not needed to create and update incidents.
Any comments you can provide about it are very welcome :)
------------------------------
Regards,
Carlos Ortigoza
Original Message:
Sent: Tue March 10, 2020 07:54 AM
From: Ben Lurie
Subject: API keys permissions details
I'm not sure if there is documentation. But if there are specific questions I may be able to answer them.
------------------------------
Ben Lurie
Original Message:
Sent: Mon March 09, 2020 05:17 AM
From: Carlos Ortigoza
Subject: API keys permissions details
Hello,
I was trying to find some documentation regarding the meaning of each of the permissions that can be assigned to a API key. During some experiments trying to create an API key with minimal permissions, I found that I had to add some of them although they seemed counter intuitive.
Just in case, I'm talking about this table:
------------------------------
Regards,
Carlos Ortigoza
------------------------------