Users without an account can't close tickets on Blesta 4.3.0

[panormitis]

I have upgraded to Blesta 4.3.0

I'm using support manager.  On some departments I have unchecked the "Allow only clients to open or reply to tickets", because I want also non-clients (without an account in Blesta) to create tickets via sending an e-mail.

If someone without an account in Blesta, visits a ticket via {update_ticket_url} he/she can't close it.

A 401 jquery error is generated when clicking the Close button and the ticket remains open.

If it's a client with an account, everything works normally.

Looks like a session issue

Please see the attached pictures

[lolgc1]

Its the update for 4.3 thats bugged. In the mysql database find "support_tickets", the bottom of the table has to be like this.

https://gyazo.com/5cb5825f066d5d641e22db0ecc437a33

The one in the middle is missing in the update and breaking the whole system, this was my solution.

[panormitis]

Hi lolgc1,

In my case, the columns are there. Please check the attached picture.

[Tiny]

I have the feeling, the error is caused by some file(s) not overwritten when upgrading. I had similar, no ticket was changing status, but updates where stored

 

 

[Paul]

I'm not able to duplicate this on a 430 b1 install upgraded to 4.3.0 final. Is anyone else having this issue upgrading from Blesta 4.2 or later?

[panormitis]

Hi Tiny & Paul,

I upgraded from Blesta 4.2 and I'm positive I overwritten all files. Actually I restored a backup and tried the upgrade twice (in case something went wrong the first time) and this issue is reproducible.

I don't know if it matters, I'm using PHP 7.2.8 and on Blesta 4.2 I was using support manager pro. Now on Blesta 4.3 I have uninstalled support manager pro and using the regular support manager.

[panormitis]

I replaced app/views/client/bootstrap/javascript/jquery.min.js with the uncompressed jquery 3.3.1.

I get an error on line 9600: xhr.send( options.hasContent && options.data || null );

Any ideas?

[Tyson]

I'm not sure what the issue is with not being able to close the ticket, although it's possible it could have something to do with the support manager pro plugin. In any case, you should revert jQuery back to the original file since v3.3.1 is a different major release from what is included with Blesta and that may break other JavaScript.

[panormitis]

Yeah, I reverted back to the original file. I only used jquery 3.3.1 for a little while 

[panormitis]

Can I perform a clean install and import the clients/packages/services etc.

Is that possible? Is there an export - import function?

[Joseph H]

Had the same issue on dev install. In my case I could not change ticket's status even in admin side. Thought the changes seemed to be already in made in the database they are not appering on the interface.

[Joseph H]

16 hours ago, Tiny said:

I have the feeling, the error is caused by some file(s) not overwritten when upgrading. I had similar, no ticket was changing status, but updates where stored

 

 

Have you tried accessing the upgrade url again? Does it still show you an upgrade option?

[Tiny]

14 minutes ago, Joseph H said:

Have you tried accessing the upgrade url again? Does it still show you an upgrade option?

In my case, a lot files did NOT overwrite when uploading for upgrading via ftp. But it's sorted now

[Joseph H]

1 minute ago, Tiny said:

In my case, a lot files did NOT overwrite when uploading for upgrading via ftp. But it's sorted now

I managed to sort my support manager case by adding the "date_updated" in the tables.

[panormitis]

In my case the files were overwritten correctly and the database seems ok.

Perhaps there is some bug/incompatibility with PHP 7.2.8.

Or perhaps the issue is occurring because I'm using reverse-proxy NGINX + Apache (I'm starting to suspect that's it).

[Tiny]

1 hour ago, panormitis said:

In my case the files were overwritten correctly and the database seems ok.

 Perhaps there is some bug/incompatibility with PHP 7.2.8.

 Or perhaps the issue is occurring because I'm using reverse-proxy NGINX + Apache (I'm starting to suspect that's it).

and you can change/create tickets and also change the status?

[panormitis]

Hi Tiny,

I performed some tests.

On some departments of support manager, I have unchecked the "Allow only clients to open or reply to tickets", because I want also non-clients (without an account in Blesta) to create tickets via sending an e-mail.

The issue only occurs on non-clients, not for everybody. If someone without an account in Blesta, visits a ticket via {update_ticket_url} he/she can't close it.

A 401 jquery error is generated when clicking the Close button and the ticket remains open.

However, clients with an account (they are required to log in to access the tickets) are not affected.

Looks like a session issue.

I have edited my first post for clarification. I didn't know it only affects users without an account.

[panormitis]

Reply button works just fine, only the Close button raises a jquery 401 error.

[Tiny]

On 8/4/2018 at 7:29 AM, panormitis said:

Can I perform a clean install and import the clients/packages/services etc.

Is that possible? Is there an export - import function?

This should be quite easy to make:

Backup/download the mysql database, create a new one, back it up is well.

With a tool like meld, you can move all over to the new one, just don't overwrite. After,  restore the changed datbase

[panormitis]

Thanks for the advice Tiny. I don't think it's the database anymore. Logged in users have no issues.

[Joseph H]

24 minutes ago, panormitis said:

Thanks for the advice Tiny. I don't think it's the database anymore. Logged in users have no issues.

Can you check the database version. Table "Settings"  find "database_version" Mine reads 4.3.0-b1 instead of 4.3.0

[panormitis]

Hi Joseph,

Mine too. 4.3.0-b1

[mesino]

@Tyson I have also stumbled across this issue of non-clients (who view a ticket via email link) being unable to close the tickets. This is on a fresh install with no extra plugins. Is that by design or is this indeed a bug?

[Jono]

Turns out it is an issue with permission for fetching the modal.  To fix you can alter app/client_controller.php starting at line 17 from

// Allow states to be fetched without login
if ($class_name == 'ClientMain' && (in_array(strtolower($this->action), ['getstates', 'setlanguage']))) {
    return;
}

to

// Allow states and dialog to be fetched without login
if ($class_name == 'ClientMain' && (in_array(strtolower($this->action), ['getstates', 'setlanguage']))
    || $class_name == 'ClientDialog'
) {
    return;
}

This fix will be included in v4.4.  See CORE-2850