Bug 235939 - otrs-2.1.5-1.fc5.noarch update breaks previous installation of otrs-2.0.4-3.fc5.noarch
otrs-2.1.5-1.fc5.noarch update breaks previous installation of otrs-2.0.4-3.f...
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: otrs (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike McGrath
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-10 17:38 EDT by Aleksander Adamowski
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-16 12:02:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Aleksander Adamowski 2007-04-10 17:38:27 EDT
Description of problem:

Latest update that has been released with Fedora Core 5 extras breaks my
installation of OTRS.

Version-Release number of selected component (if applicable):

previous version - 2.0.4-3.fc5
updated version - 2.1.5-1.fc5

How reproducible:

100 % 

Steps to Reproduce:
1. Do a yum upgrade
2. Try to open a new ticket in OTRS

Actual results:

Software error:

Can't use an undefined value as a HASH reference at
/var/www/otrs//Kernel/System/Ticket.pm line 3029.



Additional info:

Some Apache log excerpts:


1) When I login to OTRS (the main page gets displayed correctly and no errors
are visible afterwards):

==> error_log <==
[Tue Apr 10 23:35:13 2007] [notice] Digest: generating secret for digest
authentication ...
[Tue Apr 10 23:35:13 2007] [notice] Digest: done
[Tue Apr 10 23:35:13 2007] [notice] mod_python: Creating 4 session mutexes based
on 256 max processes and 0 max threads.
[Tue Apr 10 23:35:13 2007] [notice] Apache configured -- resuming normal operations
[Tue Apr 10 23:35:34 2007] -e: DBD::mysql::st execute failed: Unknown column
'q.calendar_name' in 'field list' at /var/www/otrs//Kernel/System/DB.pm line 436.
ERROR: OTRS-CGI-10 Perl: 5.8.8 OS: linux Time: Tue Apr 10 23:35:34 2007

 Message: Unknown column 'q.calendar_name' in 'field list', SQL: 'SELECT st.id,
st.escalation_start_time, q.escalation_time, st.ticket_priority_id, q.name,
q.calendar_name  FROM  queue q, ticket st  WHERE  q.escalation_time != 0  AND 
st.ticket_state_id IN ( 1, 4, 6, 7, 8 )  AND  q.id = st.queue_id  AND 
q.group_id IN ( 4, 1, 3, 2, 9, 8, 12 ) AND  st.ticket_lock_id IN ( 1, 3 )  ORDER
BY st.ticket_priority_id DESC, st.escalation_start_time ASC LIMIT 40'

 Traceback (6369): 
   Module:
Kernel::System::Ticket::IndexAccelerator::RuntimeDB::GetOverTimeTickets (v1.36)
Line: 291
   Module: Kernel::Modules::AgentTicketQueue::Run (v1.23) Line: 116
   Module: Kernel::System::Web::InterfaceAgent::Run (v1.17.2.1) Line: 671
   Module:
ModPerl::ROOT::ModPerl::Registry::var_www_otrs_bin_cgi_2dbin_index_2epl::handler
(v) Line: 47
   Module: (eval) (v1.81) Line: 203
   Module: ModPerl::RegistryCooker::run (v1.81) Line: 203
   Module: ModPerl::RegistryCooker::default_handler (v1.81) Line: 169
   Module: ModPerl::Registry::handler (v1.99) Line: 30

[Tue Apr 10 23:35:34 2007] -e: DBD::mysql::st fetchrow_array failed: fetch()
without execute() at /var/www/otrs//Kernel/System/DB.pm line 473.


2) After I try to create a new Phone ticket:

==> ssl_error_log <==
[Tue Apr 10 23:35:55 2007] [error] [Tue Apr 10 23:35:55 2007] -e: Can't use an
undefined value as a HASH reference at /var/www/otrs//Kernel/System/Ticket.pm
line 3029.\n
Comment 1 Mike McGrath 2007-04-10 17:40:07 EDT
Did you follow the directions in /usr/share/doc/otrs-2.1.5/UPGRADING ?
Comment 2 Aleksander Adamowski 2007-04-16 11:57:09 EDT
No, but I doubt any user/sysadmin expects that an official update that doesn't
traverse distribution release versions would break a working installation and
require manual intervention. This kind of beats the purpose of e.g. nightly yum
updates.

Most packages in core and extras don't have such problems, post-install scripts
usually take care of making sure the installation works after the update.

So such situation isn't expected and is likely to be seen as a bug by any user.
Comment 3 Mike McGrath 2007-04-16 12:02:33 EDT
If you think RPM should be making database calls You think wrong.  I'm sorry
your OTRS installation broke a little bit but thats what the UPGRADING files are
for.

When upstream changes the database and doesn't include an automated upgrade
that's  their decision.  Feel free to query them for a fix but the fact is I
don't run the OTRS user with the ability to alter its db schema.  Therefore
there is no technical way for this request to happen short of asking upstream
never to change the scheme ever.

Note You need to log in before you can comment on or make changes to this bug.