composer/iTop
6
0
Fork 0
mirror of https://github.com/Combodo/iTop.git synced 2026-02-12 23:14:18 +01:00
Code Issues Packages Projects Releases Wiki Activity

Fix files using CrLf, convert them to Lf to have the whole repo using Lf

Browse Source 
Warn your git config (core.autocrlf = input or true)
This commit is contained in:
Pierre Goiffon
2018-09-04 17:38:22 +02:00
parent cad18bee73
commit 40a4e6d7b0
378 changed files with 152833 additions and 152833 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2946
portal/index.php
View File

File diff suppressed because it is too large Load Diff

144
portal/readme.txt
View File

@@ -1,72 +1,72 @@
--- Customization of the portal
This is the way it is working now and is highly subject to change...
Configuration (itop-config.php)
===============================
portal_tickets: CSV value to specify which ticket classes are enabled (default to 'UserRequest')
Common constants (XML)
======================
PORTAL_POWER_USER_PROFILE: Name of the profile that determines who can see the ticket of her organization (not only the tickets she is caller for)
PORTAL_SERVICECATEGORY_QUERY: OQL to list the services (parameters available: org_id)
PORTAL_SERVICE_SUBCATEGORY_QUERY: OQL to list the service subcategories (parameters available: org_id, svc_id)
PORTAL_VALIDATE_SERVICECATEGORY_QUERY: OQL to check the service again (security against malicious HTTP POSTs)
PORTAL_VALIDATE_SERVICESUBCATEGORY_QUERY: OQL to check the service again (security against malicious HTTP POSTs)
PORTAL_ALL_PARAMS: parameters that the wizard will kindly propagate through its pages (mixing should not be a problem, default value could be cleaned a little...)
PORTAL_SET_TYPE_FROM: attribute of the class ServiceSubcategory determining the request type
PORTAL_TYPE_TO_CLASS: optional mapping from the request types to ticket classes
PORTAL_TICKETS_SEARCH_CRITERIA: comma separated list of search criteria (attcodes) for closed tickets
PORTAL_TICKETS_SEARCH_FILTER_attcode: an OQL query to limit the list of values available in the search form (drop-down list). One define per entry in PORTAL_TICKETS_SEARCH_CRITERIA
Caution: Hardcoded stuff
========================
Classes Service and ServiceSubcategory
A user can update a ticket (new/assigned)
A user can close a ticket (resolved) (user_satisfaction is hardcoded though user_comment is not)
Constants depending on the class of ticket
==========================================
For each ticket class enabled, you will have to define these constants:
PORTAL_<TICKET-CLASS>_PUBLIC_LOG: name of the public log attribute
PORTAL_<TICKET-CLASS>_USER_COMMENT: name of the user comment attribute (legacy, used to be user_commmmment)
PORTAL_<TICKET-CLASS>_FORM_ATTRIBUTES: attributes proposed to the end-user in the edition form
PORTAL_<TICKET-CLASS>_TYPE: optional attribute to be set with the value of "request type"
PORTAL_<TICKET-CLASS>_LIST_ZLIST: list of attribute displayed in the lists (opened and resolved)
PORTAL_<TICKET-CLASS>_CLOSED_ZLIST: list of attribute displayed in the list of closed tickets
PORTAL_<TICKET-CLASS>_DETAILS_ZLIST: selection and presentation of attributes in the page that shows their details
PORTAL_<TICKET-CLASS>_DISPLAY_QUERY: selection of displayable objects (use parameters contact->attcode to check things against the user/contact)
PORTAL_<TICKET-CLASS>_DISPLAY_POWERUSER_QUERY: selection of displayable objects for power users (use parameters contact->attcode to check things against the user/contact)
How to add a type of ticket (example: Incident)
===============================================
1) Add it to the list of supported tickets classes: itop-config.php/portal_tickets
2) Define PORTAL_SET_TYPE_FROM (if not already done) as the attribute of ServiceSubcategory, that will define the request type, depending on the user selection
3) Map the different values of this request type (in class ServiceSubcategory) to the supported ticket classes
YOU MUST MAKE SURE THAT ANY OF THE VALUE HAS A MAPPING SO AS TO EXCLUDE SUBCATEGORIES IF THE CORRESPONDING CLASS ARE NOT ENABLED IN THE CONFIG.
4) Make sure that the queries PORTAL_SERVICE_SUBCATEGORY_QUERY and PORTAL_VALIDATE_SERVICESUBCATEGORY_QUERY will not exclude the expected type
5) Define the various constants for this class (PORTAL_<MY-CLASS>_XXXX).
6) Adjust PORTAL_TICKETS_SEARCH_CRITERIA. Those criteria are common to all types of tickets. Giving too many criteria can lead to confusion.
7) Test, test and re-test!!!
How to copy the request type to the ticket
==========================================
1) Define PORTAL_SET_TYPE_FROM (if not already done) as the attribute of ServiceSubcategory, that will define the request type, depending on the user selection
2) Define PORTAL_<TICKET-CLASS>_TYPE as the tiket attribute code to which the request type will be copied as is. There is no mapping.
Behavior of the lists when handling several types of tickets
============================================================
There are three lists: opened tickets, resolved tickets and closed tickets.
The following explanation applies to any of those lists.
* If no item has been found, one single message is displayed (no request of this category).
* If a number of items of only one category have been found, the list is displayed as is.
* Otherwise, there are several types of tickets to display. Each sub-list is preceeded by the name of the corresponding class.
--- Customization of the portal
This is the way it is working now and is highly subject to change...
Configuration (itop-config.php)
===============================
portal_tickets: CSV value to specify which ticket classes are enabled (default to 'UserRequest')
Common constants (XML)
======================
PORTAL_POWER_USER_PROFILE: Name of the profile that determines who can see the ticket of her organization (not only the tickets she is caller for)
PORTAL_SERVICECATEGORY_QUERY: OQL to list the services (parameters available: org_id)
PORTAL_SERVICE_SUBCATEGORY_QUERY: OQL to list the service subcategories (parameters available: org_id, svc_id)
PORTAL_VALIDATE_SERVICECATEGORY_QUERY: OQL to check the service again (security against malicious HTTP POSTs)
PORTAL_VALIDATE_SERVICESUBCATEGORY_QUERY: OQL to check the service again (security against malicious HTTP POSTs)
PORTAL_ALL_PARAMS: parameters that the wizard will kindly propagate through its pages (mixing should not be a problem, default value could be cleaned a little...)
PORTAL_SET_TYPE_FROM: attribute of the class ServiceSubcategory determining the request type
PORTAL_TYPE_TO_CLASS: optional mapping from the request types to ticket classes
PORTAL_TICKETS_SEARCH_CRITERIA: comma separated list of search criteria (attcodes) for closed tickets
PORTAL_TICKETS_SEARCH_FILTER_attcode: an OQL query to limit the list of values available in the search form (drop-down list). One define per entry in PORTAL_TICKETS_SEARCH_CRITERIA
Caution: Hardcoded stuff
========================
Classes Service and ServiceSubcategory
A user can update a ticket (new/assigned)
A user can close a ticket (resolved) (user_satisfaction is hardcoded though user_comment is not)
Constants depending on the class of ticket
==========================================
For each ticket class enabled, you will have to define these constants:
PORTAL_<TICKET-CLASS>_PUBLIC_LOG: name of the public log attribute
PORTAL_<TICKET-CLASS>_USER_COMMENT: name of the user comment attribute (legacy, used to be user_commmmment)
PORTAL_<TICKET-CLASS>_FORM_ATTRIBUTES: attributes proposed to the end-user in the edition form
PORTAL_<TICKET-CLASS>_TYPE: optional attribute to be set with the value of "request type"
PORTAL_<TICKET-CLASS>_LIST_ZLIST: list of attribute displayed in the lists (opened and resolved)
PORTAL_<TICKET-CLASS>_CLOSED_ZLIST: list of attribute displayed in the list of closed tickets
PORTAL_<TICKET-CLASS>_DETAILS_ZLIST: selection and presentation of attributes in the page that shows their details
PORTAL_<TICKET-CLASS>_DISPLAY_QUERY: selection of displayable objects (use parameters contact->attcode to check things against the user/contact)
PORTAL_<TICKET-CLASS>_DISPLAY_POWERUSER_QUERY: selection of displayable objects for power users (use parameters contact->attcode to check things against the user/contact)
How to add a type of ticket (example: Incident)
===============================================
1) Add it to the list of supported tickets classes: itop-config.php/portal_tickets
2) Define PORTAL_SET_TYPE_FROM (if not already done) as the attribute of ServiceSubcategory, that will define the request type, depending on the user selection
3) Map the different values of this request type (in class ServiceSubcategory) to the supported ticket classes
YOU MUST MAKE SURE THAT ANY OF THE VALUE HAS A MAPPING SO AS TO EXCLUDE SUBCATEGORIES IF THE CORRESPONDING CLASS ARE NOT ENABLED IN THE CONFIG.
4) Make sure that the queries PORTAL_SERVICE_SUBCATEGORY_QUERY and PORTAL_VALIDATE_SERVICESUBCATEGORY_QUERY will not exclude the expected type
5) Define the various constants for this class (PORTAL_<MY-CLASS>_XXXX).
6) Adjust PORTAL_TICKETS_SEARCH_CRITERIA. Those criteria are common to all types of tickets. Giving too many criteria can lead to confusion.
7) Test, test and re-test!!!
How to copy the request type to the ticket
==========================================
1) Define PORTAL_SET_TYPE_FROM (if not already done) as the attribute of ServiceSubcategory, that will define the request type, depending on the user selection
2) Define PORTAL_<TICKET-CLASS>_TYPE as the tiket attribute code to which the request type will be copied as is. There is no mapping.
Behavior of the lists when handling several types of tickets
============================================================
There are three lists: opened tickets, resolved tickets and closed tickets.
The following explanation applies to any of those lists.
* If no item has been found, one single message is displayed (no request of this category).
* If a number of items of only one category have been found, the list is displayed as is.
* Otherwise, there are several types of tickets to display. Each sub-list is preceeded by the name of the corresponding class.