Hi Francois,
i dont think anybody will answer your question because you missed few words in it. Is your concern if there is difference between i-doit and iTop? There are differences between these products since they come from different companies. Have a look on features for each product to see details.
http://www.combodo.com/-Features-.html
http://www.i-doit.org/en/about-i-doit/83-2/
J.
which specific technologies do you mean?
does it mean that you know about the issue and it has been fixed in 0.9.9.6 or that you don't support older than current versions?
Connecting i-doit and OTRS gives i-doit great new possibilities! We are exciting to hear about such feature.
Please keep us updated on this topic!
Dear I-Doit team,
we have data inconsistency in tables isys_person_intern across all Mandants. By inconsistency i mean that userX has in first mandant id 44 and id 25 in second Mandant. This becomes problem in case user wants to swicht mandant using drop-down menu (left top corner of I-Doit interface) and becomes following error:
isys_exception_database : Query error: 'UPDATE isys_user_session SET isys_user_session__isys_person_intern__id ='44' WHERE isys_user_session__php_sid='ca6a46ae4afbd436f5944cc6d06f9ef9';': Cannot add or update a child row: a foreign key constraint fails (`idoitnew_mandant2/isys_user_session`, CONSTRAINT `isys_user_session_ibfk_1` FOREIGN KEY (`isys_user_session__isys_person_intern__id`) REFERENCES `isys_person_intern` (`isys_person_intern__id`) O) :CMDB > Server > rvimsapps > Übersichtsseite
Logged in as: userx
Idoit version: 0.9.9-1
My guess is that inconsistency begins once you work just with one Mandant for some time (and users are created in mandant1 schema) and then you create second mandant. Users will login into system and they are created in mandant2.isys_person_intern under different IDs (depends in which order they login for the first time after second mandant was created) than it is in first schema (mandant1).
Can you please have a look on this bug?
Hi Christian,
thats correct. Just enough is to create new Mandant and forget to change default passwords for default users.
Dear I-Doit,
it is possible to import (upload) php file and then execute it using URL: http://yourserver/imports/evil.php
Modul: Import
tested on versions: 0.9.9-1 and 0.9.9-5
Requirements: active account with import rights is required to complete such attack
my guess is that creating .htaccess file with "php_flag engine off" inside imports directory could solve the problem temporarry.
SOLVED: problem is in our database - foreign keys are missing. They were not created for some strange reason
Update runs smoothly after creating foreign keys
Dear i-doit team,
we are trying to upgrade our version to 0.9.9-2 but following error occurs
isys_exception_database : Query error: 'ALTER TABLE isys_catg_drive_list DROP FOREIGN KEY isys_catg_drive_list_ibfk_3': Error on rename of './idoitnew_mandant/isys_catg_drive_list' to './idoitnew_mandant/#sql2-37fc-798' (errno: 152)
It seems that this table has no such FOREIGN KEY
mysql> SHOW CREATE TABLE isys_catg_drive_list\G
*************************** 1. row ***************************
Table: isys_catg_drive_list
Create Table: CREATE TABLE isys_catg_drive_list (
isys_catg_drive_list__id int(10) unsigned NOT NULL AUTO_INCREMENT,
isys_catg_drive_list__isys_stor_raid_level__id int(10) unsigned DEFAULT NULL,
isys_catg_drive_list__isys_filesystem_type__id int(10) unsigned DEFAULT NULL,
isys_catg_drive_list__isys_stor_unit__id int(10) unsigned DEFAULT NULL,
isys_catg_drive_list__isys_memory_unit__id int(10) unsigned DEFAULT NULL,
isys_catg_drive_list__isys_catd_drive_type__id int(10) unsigned DEFAULT NULL,
isys_catg_drive_list__id__raid_pool int(10) unsigned DEFAULT NULL,
isys_catg_drive_list__title varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
isys_catg_drive_list__capacity bigint(20) DEFAULT NULL,
isys_catg_drive_list__description text COLLATE utf8_unicode_ci,
isys_catg_drive_list__driveletter varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
isys_catg_drive_list__partitionmapping varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
isys_catg_drive_list__filesystem varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
isys_catg_drive_list__sort int(10) unsigned DEFAULT '5',
isys_catg_drive_list__const varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
isys_catg_drive_list__property int(10) unsigned DEFAULT '0',
isys_catg_drive_list__status int(10) unsigned DEFAULT '2',
isys_catg_drive_list__isys_obj__id int(10) unsigned DEFAULT NULL,
PRIMARY KEY (isys_catg_drive_list__id),
KEY isys_catd_drive_list_FKIndex2 (isys_catg_drive_list__id__raid_pool),
KEY isys_catd_drive_list_FKIndex3 (isys_catg_drive_list__isys_catd_drive_type__id),
KEY isys_catd_drive_list_FKIndex4 (isys_catg_drive_list__isys_stor_unit__id),
KEY isys_catd_drive_list_FKIndex5 (isys_catg_drive_list__isys_filesystem_type__id),
KEY isys_catd_drive_list_FKIndex6 (isys_catg_drive_list__isys_stor_raid_level__id),
KEY isys_catd_drive_list__isys_memory_unit__id (isys_catg_drive_list__isys_memory_unit__id),
KEY isys_catg_drive_list__isys_obj__id (isys_catg_drive_list__isys_obj__id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
1 row in set (0.00 sec)
Do you know about some workaround that we can continue with upgrade?