I'm trying to customize iTop to my needs and I have some questions about the use of some attributes (or new ones proposed):
I don't understand the utility of HierarchicalKey, I thought that its use on Organization hierarchy will imply that an OQL query selection based on a given Organization will also filter/select the children orgs, but this is not the case (all organizations are individual entities on iTop usage). I will like for example to assign devices/apps from the parent org to some CIs on children orgs. So for example to filter devices for an organization or parent one (to share CIs):
SELECT Device
JOIN Organization AS SubOrg ON Device.org_id = SubOrg.id
JOIN Organization AS RootOrg ON SubOrg.parent_id BELOW RootOrg.id
WHERE RootOrg.id = org_id
I also don't understand the strange (IMHO) SQL implementation of CaseLog for tickets as lonely attribute in a table with the full log instead to store each log-comment as a row and then point to each belonging Ticket (as is usually implemente on other apps like this). This will ease the import of bugs/incidents/requests/… from other apps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
I'm trying to customize iTop to my needs and I have some questions about the use of some attributes (or new ones proposed):
I don't understand the utility of HierarchicalKey, I thought that its use on Organization hierarchy will imply that an OQL query selection based on a given Organization will also filter/select the children orgs, but this is not the case (all organizations are individual entities on iTop usage). I will like for example to assign devices/apps from the parent org to some CIs on children orgs. So for example to filter devices for an organization or parent one (to share CIs):
SELECT Device
JOIN Organization AS SubOrg ON Device.org_id = SubOrg.id
JOIN Organization AS RootOrg ON SubOrg.parent_id BELOW RootOrg.id
WHERE RootOrg.id = org_id
I also don't understand the strange (IMHO) SQL implementation of CaseLog for tickets as lonely attribute in a table with the full log instead to store each log-comment as a row and then point to each belonging Ticket (as is usually implemente on other apps like this). This will ease the import of bugs/incidents/requests/… from other apps.