Hello, I am trying to figure out if there is a way to create a profile for Incidents that only allow assigned individuals to view, create, and edit incidents and no access to anything else? I have tried looking at profile creation but am not sure I am doing it right. If it is possible, do you have suggestions or an example I could use for reference?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the reply. I have already been through that documentation but there is still an issue. I was able to take the default iTop ITIL profile XML file for an example and have been modifying it somewhat successfully. I already created the new blank module, installed it under iTop, already have the toolkit installed, and am currently at the stage of tweaking the XML file.
When I checked inside the toolkit, it reported no issues so I proceeded to install it (on a dev system mind you). When I look at the Grant Matrix it shows what I want, which is the user only having access to Incidents and nothing else (image profileName.png & image profileGrantMatrix). However, when I try and have the test user login I am greeted with the error presented in the image testUserError.png.
I noticed that under most (if not all) of your different profiles you have the following code:
That does allow the test user to login but then the Grant Matrix is wide open again on reads which is what I am trying to avoid in the first place. I have tried inputting custom groups to fix the login error (testUserError.png) such as:
This code passes the Data Model verification in the toolkit but ends up giving me a PHP error while compiling the database on re-install so this id must not exist in a usable fashion.
What I need to know, which I have not seen so far in the documentation, is the minimum requirement for access without straight up giving this profile
<group id="*">
access. Do you know what the minimum read allowances are to have this profile access the Standard Portal but only on the Incident section? Is this even possible or do I need to have a * group and manage other access like the example below?
The answer is probably not so easy to give. Just the incident will never be enough. A user must be allowed to read contact (for his own person), probably his own organization also, then read access to any class which can be linked to an Incident might be required or have side effect to be checked...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the reply. It has been sort of a hunt and peck process but I have managed to scrape together something that works well enough for what we are looking for. The main reason we needed a profile similar to this is because we are using the Incident portion of iTop for safety reporting and auditing. I know iTop is only designed for IT use but was told to try and convert the Incident section over for safety purposes. Hints the reason to try and lock out Incident agents from being able to access information like our Helpdesk tickets, Licenses, Software, Computers, etc. If needed, I will try and perform further tweaks on it but for now is accomplishes the critical goals.
Hello, I am trying to figure out if there is a way to create a profile for Incidents that only allow assigned individuals to view, create, and edit incidents and no access to anything else? I have tried looking at profile creation but am not sure I am doing it right. If it is possible, do you have suggestions or an example I could use for reference?
Hello,
This was asked just a few days ago :)
Have a look at this setp by step tutorial : Creating new Profiles [iTop Documentation]
Thank you for the reply. I have already been through that documentation but there is still an issue. I was able to take the default iTop ITIL profile XML file for an example and have been modifying it somewhat successfully. I already created the new blank module, installed it under iTop, already have the toolkit installed, and am currently at the stage of tweaking the XML file.
Here is what my current XML document looks like.
When I checked inside the toolkit, it reported no issues so I proceeded to install it (on a dev system mind you). When I look at the Grant Matrix it shows what I want, which is the user only having access to Incidents and nothing else (image profileName.png & image profileGrantMatrix). However, when I try and have the test user login I am greeted with the error presented in the image testUserError.png.
I noticed that under most (if not all) of your different profiles you have the following code:
That does allow the test user to login but then the Grant Matrix is wide open again on reads which is what I am trying to avoid in the first place. I have tried inputting custom groups to fix the login error (testUserError.png) such as:
This code passes the Data Model verification in the toolkit but ends up giving me a PHP error while compiling the database on re-install so this id must not exist in a usable fashion.
What I need to know, which I have not seen so far in the documentation, is the minimum requirement for access without straight up giving this profile
access. Do you know what the minimum read allowances are to have this profile access the Standard Portal but only on the Incident section? Is this even possible or do I need to have a * group and manage other access like the example below?
Please let me know what options there are.
Last edit: Mark Stewart 2020-02-12
Profile Name Image
Profile Grant Matrix
Does anyone have an idea if this can be done? I would prefer to get a "no" answer then nothing at all.
The answer is probably not so easy to give. Just the incident will never be enough. A user must be allowed to read contact (for his own person), probably his own organization also, then read access to any class which can be linked to an Incident might be required or have side effect to be checked...
Thank you for the reply. It has been sort of a hunt and peck process but I have managed to scrape together something that works well enough for what we are looking for. The main reason we needed a profile similar to this is because we are using the Incident portion of iTop for safety reporting and auditing. I know iTop is only designed for IT use but was told to try and convert the Incident section over for safety purposes. Hints the reason to try and lock out Incident agents from being able to access information like our Helpdesk tickets, Licenses, Software, Computers, etc. If needed, I will try and perform further tweaks on it but for now is accomplishes the critical goals.