Turns out I still had an old cron job in /etc/crontab running at the same time and using an old php version!

That's me done for the night. Lets see if I can get 3 hours sleep before work!

KevinTheJedi thanks for all your help

KevinTheJedi
I've got all but one of the mail account able to authenticate and send mail. Thanks for getting me over those hurdles.

My last query on the email is related to email scraping.
I've enabled the Email Fetching with absolutely no results.
I set the cron job to fire off every 5 minutes but nothing was happening until I ticked "fetch on autocron" on the email settings and options page. It then scraped emails.

The help for the Fetch on autocron says it won't work if no one is logged in. Is this the case even if there is a system cron job running in the background?

What can I look at to either get the system cron job scraping properly or get the imap polling working?

KevinTheJedi
One further question, we scrape multiple mailboxes. I'm seeing that it generates a new instance in the Oauth2 client for each mailbox. Do we need to create individual apps within azure or will a single app be ok to share amongst the mailboxes?

Thanks Kevin, my flu addled brain hadn't thought of that!

That cured the problem

Debian 11
Apache 2.4.54
MariaDB 10.5.18
PHP 8.1
I've had a rocky ride upgrading from 1.15.8 to 1.17.2 but after a lot of swearing at some of the plugins, the web site part of things is working! Unfortunately, the email is being an arse!

I've carefully gone through the guide https://docs.osticket.com/en/latest/OAuth2/Microsoft%20Authorization%20Guide.html

My problem comes when I login and approve the app, It returns me to my site with a 404 page. It's pointing to the Callback Endpoint and ends in
/oauth2?code=.......
It's stating URL not found.

I'm getting nothing useful in the logs either!
Can anyone give me a clue on this?

KevinTheJedi Will a simple upgrade work going from 1.15 to 1.17 as I read in some of the threads here that I probably need to migrate in which case, from the upgrade and migration page....

Migration
We plan on supporting data migration from previous discontinued versions of osTicket as well as 3rd party help desks in the near future. Please check the forums for up to date discussions on the subject.

We are currently running v1.15.8 and need to migrate to v1.17
From my browsing, I understand the database is different between the two version. If so, what's the best way to migrate my data across?

Firstly, thank you for the great software, we've been using this for many years now and have dealt with close to 100,000 tickets now. Previously we've been using AD for logins and exchange group mailboxes for the helpdesk emails with the helpdesk configured to move the emails to a different folder once the ticket has created.

We are now looking at a major sea change and are considering OpenLDAP and Google Workspace. I was wondering if anyone has this setup already and what issues they had setting OSTicket up? I'm wondering about the mailbox scraping within gmail as it doesn't have folders to move the actioned emails to?

Thanks in advance

Thanks for the reply Kevin, the problem is I'm getting 1000's of these errors, constantly!
I've fixed the issue on the old helpdesk so will roll back to that for now and try a fresh attempt at the new version!

osTicket: 1.16.3
php: 8.0
os: debian 11
db: mariadb 10.5.15
After a bit of an issue yesterday, I've done a clean build of the helpdesk overnight and opened it up this morning.
I am getting constant DB Error #1048's (hundreds so far) along the lines of
[INSERT INTO ost_form_entry_values(entry_id, field_id, value)
values (
(SELECT id FROM ost_form_entry WHERE object_id = (SELECT user_id FROM ost_user_account WHERE user_id = '37') AND form_id = 1),
(SELECT id FROM ost_form_field WHERE name = 'usertitle' AND form_id = 1), "WMS Consultant")
ON DUPLICATE KEY UPDATE value = "WMS Consultant";]

Column 'field_id' cannot be null<br />
<br />
---- Backtrace ----<br />
#0 (root)/include/mysqli.php(201): osTicket->logDBError()<br />
#1 (root)/scp/sync_mldap.php(332): db_query()<br />
#2 (root)/scp/sync_mldap.php(561): SyncLDAPMultiClass->update_users()<br />
#3 (root)/include/plugins/multi-ldap/auth.php(134): SyncLDAPMultiClass->check_users()<br />
#4 (root)/include/class.signal.php(98): LdapMultiAuthPlugin->onCronProcessed()<br />
#5 (root)/scp/autocron.php(66): Signal::send()<br />
#6 {main}

form_id = 1 relates to the customer info form
Can someone give me a clue on this before my mailbox implodes with the notifications?

Thanks KevinTheJedi, it was one of the searches I use for my monthly reports!
I'm going to look at using our Siebel or setup PowerBi to get the reports I think!

KevinTheJedi
We do have a slightly customized global queue but I do have a lot of personal queues and searches as I need to pull data out for monthly reports. I will try clear those out and see if it makes a difference

ntozier
Apologies, was struggling to focus on the screen last night when I posted
MySql 10.5.15
PHP is still running 7.3.33 - I will look at changing that to 7.4
Slow query logs - Where are those? I've checked the "system logs" through the admin panel and logging is set to debug. I've also check the syslog and apache logs and can't see anything in obvious there?

We were running 1.15.4 on Debian 10 with no issues. We then upgraded the host OS to Debian 11 and since that upgrade, everything I do in the scp pages of the site runs slow and takes ages. I've since upgraded the site to 1.15.7 and still face the same issue.

This is only impacting my login, all the rest of the agents are ok as is the master account! I've tried clearing out my browser files/cache/cookies, different browsers, different pc's. We use the multi-ldap plugin as we have users in several domains and I've tried turning off the agent ldap and going back to local password for my account. It's not made a bit of difference.

The problem looks to be only with my account and it's the "working" day to day account to run the helpdesk with full access to all departments! I'd rather not delete the account and start again as that would be a complete pain. Can anyone advise where I should be looking to try figure out what's causing this for me?

I'm wanting to add information to the "User Directory" and "Organizations" pages and need a bit of advice.

On the User Directory page, I would like to add in a column showing the Organization the user belongs to or not.
I've tracked the generated table down to ''include/staff/users.inc.php'' and added in the column to the table but I'm not sure how to pull the organization (not the org code)?

With the Organization page, we have added two form fields to the "Organization Information" form with the variable names org-gmc and org-sc. Both of these are Yes/No choices. I would like to display these variables in the Organization page.

I'm a spanner monkey, not a coder so need some help/guidance on this

Thanks

We are using ldap for around 90% of our current users.
3 registered user accounts had the issue that when you clicked on them from the user list, you got a http 500 page. You couldn't raise a ticket on their behalf and couldn't do any changes to their account through the web inteface.

In an attempt to remove them manually from the database, I was going through the various user tables. When I deleted their entries out of the user_account table, we were able to access their details in the user list. Once i'd done that with all 3 users, next time the cron job ran, it cleared the mail inbox correctly

https://forum.osticket.com/d/96449-resolved-unable-to-untick-claim-on-response-disable-auto-claim/2

Apparently, a bug! I've done the edit and it's playing now.

We are running v1.14.1
PHP 7.3.14-1
on a Debian 9 with Apache 2.4.25

We are monitoring several different mailboxes and in each mailbox there is a folder "tickets" where the emails should be moved to. It is creating two copies of the emails but leaving the original in the inbox!

Please advise on this as it's getting quite messy and difficult to track what's going on with the emails and tickets.
This worked perfectly on our old server running v1.10!

I'm running a new install of v1.14.1 (f1e9e88) and using php 7.3.14-1
On settings\tickets I've got "claim on response" enabled
Unfortunately, for all my departments the "disable auto claim" box is ticked and when I un-tick and save, it immediately re-ticks the box!

Anyone give me a clue on how to fix this?