I'm in the process of upgrading three rather old version of OTRS (2.0.x)
to a newer one (3.0.x).
The current setup has been initially setup in 2006 and took some custom
modifications. The extend of modifications if (of course) today unknown.
In an initial attempt to see how far we can upgrade the current
OTRS/database (2.0.x), I've duplicated the setup of one database and
OTRS installation on a virtual machine and applied the update steps:
Version 2.0 -> 2.1 -> 2.2 -> 2.3 -> 2.4 -> 3.0 -> 3.1 -> 3.2
I managed to get to version 3.1, but any upgrade higher failed during
the database upgrade procedure. So we decided that 3.1 would suffice.
The test scenario on a virtual machine has been done with the medium
size database (30G) and took it's time. Another installation with a
smaller database got a higher priority, so that's where I had to start.
I've automated most of the steps that adjust to our environment and
implement the code directly from the GIT repository. The version tags in
the repository are used as version reference for the source files.
Contrary to the test upgrade on the virtual machine, the upgrade fails
at Version 2.3. During the upgrade procedure I see a lot of steps
especially during the Database conversion, all referring to certain
columns not being found.
This got me thinking where the differences would be and I started
It seems that previous update script belonging to previous versions are
being updated in later versions. Though the changes seem to marginal in
this example, I must assume that this could affect the update scripts
running. For example:
Comparing the MySQL upgrade script to OTRS version 2.1 in version 2.1
and 2.1.3 shows differences:
$ git diff rel-2_1_1..rel-2_1_3 scripts/DBUpdate-to-2.1.mysql.sql
If this changed, I must assume other changes as well which could prevent
me from upgrading. This requires more testing on my side in order to
figure out which version of the script I actually should apply in order
to get the update working.
The database of the OTRS installation supposedly being upgraded first
(v2.0.4), differs from the one created by a "fresh" installation of
2.0.4. I didn't have the time to go through all 2000 lines of the `git
diff`-output, but most changes seem to be rather minor. Anyway: there
are changes, which means the version we're running isn't the one that
current default installation of 2.0.4 brings in. In the light of the
customization changes of earlier days it is likely that there are
changes in the database structure as well.
Is there a simple explanation why the upgrade fails other than possible
database changes and an explanation I do not see? Is there anybody who
has done a full upgrade from version 2.0.x to at least v3.x.x?
Am I missing something important?
I have some alternatives on how I can go on (for now):
1. Leaving the old installation behind and start filling a recent one
from the beginng.
2. Testing if different DB upgrade scripts give different results.
3. Upgrading to one version, dropping the database structure,
re-importing the standard structure of that version and importing the
4. Hiring the OTRS support company to do the upgrades.
# Technical Summary
* OS: CentOS 6.5 (Web and DB Server)
* MySQL: 5.1.69
* Databases: 20GB, 30GB, 500GB
* OTRS, v2.0.4(2x), v2.0.5(1x)
Please bother me with questions if there are any. Any pointing into any
other direction where I might find a working upgrade at the end:
I am currently evaluating OTRS 3.2.13 for implementation to manage all our tickets and faults and all the ITSM related issues in the broadcast company I work at.
I have ITSM core and all the other required modules installed to manage this functionality but am struggling with the way in which a Custom Catalog Class is displayed.
One can add a Custom Class - but this doesnt appear as an additional class within the Admin>>Config items area. It does appear within the General Catalog (as per the attached screenshot). I would like to add a separate Custom Catalog Class not as a subclass of the ITSM::ConfigItem::Computer::Type according to all the mailing lists but as a separate Class Called ITSM::ConfigItem::Broadcast::Type with its own Config Items)
So the question really is - how do I add Custom Catalog Classes AND make it appear in the General Catalog area?
My System is OTRS 3.2.13
running on Server version: 5.5.34-0ubuntu0.12.04.1
MySQL client version: 5.5.34
PHP extension: mysqli
Timeline Television, Queen Elizabeth Olympic Park
IBC, Waterden Road, Queen Elizabeth Olympic Park, Stratford, London, E15 2EE
gus.hauptfleisch(a)timeline.tv<mailto:email@example.com> \ T: +44 208 221 6885 M: +44 7775 650 688
I’m using OTRS at a UK company, where we have an offshore support team in India. For their queue, I’m trying to create a calendar appropriate to their business hours; however OTRS will not let me set their timezone to UTC +5:30 as the drop-down list only contains hourly intervals.
How do we create calendars for countries whose timezones are not a simple multiple of hours from GMT/UTC?
I have been working on some process and I have an activtiy where the user
can update some fields (Category, priority, Service and SLA) but when we
try to execute this activity we get an error that says "Permission denied
on TicketID: 103226!" and says Cannot Set ServiceID on TicketID 103226
I do have all the permissions on the group.
Has anyone go through this?
Alvaro Cordero Retana
Consultor de Tecnologias
Gridshield Monitoreo de Redes e
2258-5757 ext 123