As per the screenshot, i've had a couple of instances of new tickets being generated but no content being shown.
Additionally when attempting to use the reply function button, nothing happens.
Notably I have my osTicket installation setup to send me an email when a new ticket is created - this trigger correctly and the admin email contains the content submitted along with the ticket, this content simply doesn't show within osTicket itself.
Any thoughts?
Seems to me like it's an issue where there are multiple threads for the same object_id in the database. Any who, you should first post a screenshot of Admin Panel > Dashboard > Information tab so we can see what your environment looks like. Secondly, you need to check your logs (general server logs, webserver error logs, PHP error logs, MySQL/MariaDB error logs, osTicket System Logs, Browser Console logs, etc.) for any related errors.
Cheers.
Thanks for the input KevinTheJedi
Prior to pulling up the error logs, I've also had a number of DB errors. Notably the day prior to this issue, I decreased the default cron job call from once every minute, down to once every 5 minutes - this was due to rare cron errors which SiteGround highlighted was likely purely down to too many requests over a short period of time.
The following is from 4 different email alerts.
[INSERT INTO soft_user__cdata SET notes='', user_id= 7 ON DUPLICATE KEY UPDATE notes='']
Unknown column 'notes' in 'field list'<br />
<br />
---- Backtrace ----<br />
#0 (root)/include/mysqli.php(201): osTicket->logDBError('DB Error #1054', '[INSERT INTO s...')<br />so...')<br />
#1 (root)/include/class.dynamic_forms.php(381): db_query('INSERT INTO
#2 (root)/include/class.dynamic_forms.php(396): DynamicForm::updateDynamicDataView(Object(DynamicFormEntryAnswer), NULL)<br />
#3 (root)/include/class.signal.php(98): DynamicForm::updateDynamicFormEntryAnswer(Object(DynamicFormEntryAnswer), NULL)<br />
#4 (root)/include/class.orm.php(680): Signal::send('model.created', Object(DynamicFormEntryAnswer))<br />
#5 (root)/include/class.dynamic_forms.php(1536): VerySimpleModel->save(false)<br />
#6 (root)/include/class.dynamic_forms.php(1378): DynamicFormEntryAnswer->save(false)<br />
#7 (root)/include/class.dynamic_forms.php(1317): DynamicFormEntry->saveAnswers(NULL, false)<br />
#8 (root)/include/class.user.php(348): DynamicFormEntry->save()<br />
#9 (root)/include/class.user.php(421): User->addForm(Object(UserForm), 1, Array)<br />
#10 (root)/include/class.user.php(249): User->addDynamicData(Array)<br />
#11 (root)/include/class.ticket.php(4206): User::fromVars(Array, true)<br />
#12 (root)/include/class.mailfetch.php(905): Ticket::create(Array, Array, 'Email')<br />
#13 (root)/include/class.mailfetch.php(954): MailFetcher->createTicket(1)<br />
#14 (root)/include/class.mailfetch.php(1034): MailFetcher->fetchEmails()<br />
#15 (root)/include/class.cron.php(25): MailFetcher::run()<br />
#16 (root)/include/class.cron.php(110): Cron::MailFetcher()<br />
#17 (root)/include/api.cron.php(19): Cron::run()<br />
#18 (root)/include/api.cron.php(40): CronApiController->run()<br />
#19 (root)/api/cron.php(23): LocalCronApiController::call()<br />
#20 {main}
[INSERT INTO soft_user__cdata SET phone='', user_id= 7 ON DUPLICATE KEY UPDATE phone='']
Unknown column 'phone' in 'field list'<br />
[INSERT INTO soft_user__cdata SET notes='', user_id= 8 ON DUPLICATE KEY UPDATE notes='']
Unknown column 'notes' in 'field list'<br />
[INSERT INTO soft_user__cdata SET phone='', user_id= 8 ON DUPLICATE KEY UPDATE phone='']
Unknown column 'phone' in 'field list'<br />
Okay so those errors are all related and are very easy to resolve. All you need to do is drop the ost_user__cdata table and run cron manually once and that should regenerate the tables with the appropriate columns. Afterwards the data will be repopulated in batches via subsequent cron runs.
Cheers.
Excellent, thanks. I will drop the table and wait for the once per 5 minute cron to run.
Beyond that, will this adjustment fix the fact that the ticket content was in the email alert but not within the platform itself or is that an entirely different issue?
Notably as highlighted previously, the reply button also doesn't work however I would presume this is done to the initial ticket content simply not being visible (despite appearing in the email notification on ticket creation).
So the threads not appearing might be a separate issue or it might be related to the CDATA. I don’t think it’s related to the CDATA issue but you might get lucky. Typically when the thread isn’t showing it means when the ticket goes to look up the thread and finds two thread records when there should only be one. But this typically throws a fatal error that you’d see in your logs.
As far as the Reply button goes, I believe it’s not working because of the thread issue.
Cheers.
Ok, so I've tried to generate a test ticket. This was successful, again no content in the ticket once it reached the osTicket inbox.
Admin Panel > Manage > Lists - there is only one custom list, and this is Ticket Statuses.
Looking into the DB, under ost_thread there are 6 entries with no duplicate id numbers (3, 4, 5, 6, 7, 9).
Whilst in ost_thread_entry there are 7 entries, again no duplicate id values (4, 5, 6, 7, 8, 9, 11).
Shortly after generating some test tickets, a further DB error email was generated.
[INSERT INTO soft_attachment SET type = 'H', object_id = 12, file_id = 1, inline = 1]
Duplicate entry '1-12' for key 'file_object'<br />
<br />
---- Backtrace ----<br />
#0 (root)/include/mysqli.php(201): osTicket->logDBError('DB Error #1062', '[INSERT INTO s...')<br />so...', true, true)<br />
#1 (root)/include/class.orm.php(3466): db_query('INSERT INTO
#2 (root)/include/class.orm.php(658): MySqlExecutor->execute()<br />
#3 (root)/include/class.thread.php(1253): VerySimpleModel->save()<br />
#4 (root)/include/class.thread.php(1261): ThreadEntry->createAttachment(Array, 'powered-by-osti...')<br />
#5 (root)/include/class.thread.php(1800): ThreadEntry->createAttachments(Array)<br />
#6 (root)/include/class.thread.php(1812): ThreadEntry::create(Array)<br />
#7 (root)/include/class.thread.php(2944): ThreadEntry::add(Array)<br />
#8 (root)/include/class.thread.php(3159): MessageThreadEntry::add(Array, Array)<br />
#9 (root)/include/class.ticket.php(3134): ObjectThread->addMessage(Array, Array)<br />
#10 (root)/include/class.ticket.php(4417): Ticket->postMessage(Array, 'Email', false)<br />
#11 (root)/include/class.mailfetch.php(905): Ticket::create(Array, Array, 'Email')<br />
#12 (root)/include/class.mailfetch.php(954): MailFetcher->createTicket(1)<br />
#13 (root)/include/class.mailfetch.php(1034): MailFetcher->fetchEmails()<br />
#14 (root)/include/class.cron.php(25): MailFetcher::run()<br />
#15 (root)/include/class.cron.php(110): Cron::MailFetcher()<br />
#16 (root)/include/api.cron.php(19): Cron::run()<br />
#17 (root)/include/api.cron.php(40): CronApiController->run()<br />
#18 (root)/api/cron.php(23): LocalCronApiController::call()<br />
#19 {main}
Any recommendations/next steps?
Sounds like you’re having a whole slew of random issues. I would upgrade to v1.15.7 and retest.
Cheers.
KevinTheJedi Would you recommend updating to v1.15.7 or just biting he bullet and going for v1.16.2?
I would try v1.15.7 as that’s the easiest route. If that’s working it’ll give you enough time to prepare for 1.16.x or when v1.17 comes out you can upgrade to that. If you use email fetching you’ll want to use v1.17 when it comes out as it will have Modern Authentication (OAuth2.0) support for fetching; gmail and ms are forcing that soon.
Cheers.
KevinTheJedi I've tried the update to 1.15.7 and 1.16.2 and both wouldn't display the email content (on existing tickets and even new tickets) so I've started afresh (as there were only test tickets really in the install) used app installer for 1.15.6 and then upgrade to 1.16.2 without any issues, whilst also having tested inbound emails which are currently getting pulled into the system properly. Originally when I installed osTicket i had no issues and they only start appearing sporadically so a case of seeing how it performs and fully testing I think. Fingers crossed this time around with a clean install and upgrade.
I’m thinking maybe at some point there was a bug or an issue that caused duplicate records or something, or maybe one or more tables became corrupted, etc.
I do know that in the past a few people were using older versions of MySQL (before MySQL 8) and that caused duplicate records and such after MySQL reboot. Here is a quote from me on an older thread about this subject:
In versions previous to 8.0 the auto_increment value was stored in memory and not on disk so if MySQL restarts then it loses the auto_increment value and is reset; see this SO post for more info.
With this being said, I'd highly recommend upgrading MySQL to 8.0+.
Cheers.
