Trying to get property of non-object -> Email Assign Notification about ticketit

[fusiondesign]

Yeah, same problem I ran into. I have never seen the unserialize method used so I'm not sure about a fix. It's basically saying that it ran into some bad data while trying to unserialize. I can't figure out why or proper steps to debug since the Model objects are so large

[fishmad]

It was working fine 1 hour ago, so I don't think its related to the authenticated users as its now happening to all admin,agent and user,

The only things I have changed in the last hour is: delete all my Statuses and Removed all Agents via admin UI, I then re-added some Statuses and Agents and the auto incrementing MySQL IDs are higher - Statuses now start a #7 instead of the original #1 - I recalled seeing something in the code about #1 being the default assigned to new tickets - might be something worth looking at.

[fusiondesign]

Can you try removing {!! Form::hidden('agent_id', 'auto') !!} from the ticket create form and tell me if it fixes it? That's the only change to the repo

[fishmad]

Confirmed: reset first SQL row for Statuses to ID 1 and it worked, the email sent fine.

[fusiondesign]

Did you update
'default_status_id' => 1, in config?

[fusiondesign]

If an improper value is set there, it may be the cause of all serialize problems. Please confirm! :)

[fishmad]

My 'default_status_id' => 1,

but my database rows started at 7 because I deleted all my statuses earlier tonight

[fusiondesign]

If you change back to 7 and change config to 7, does it also still work?

[fishmad]

I just tried, changed both config and DB to 7 and the email worked.

than just to check again I changed config to random number of 4 left DB at 7 and it crashed while trying to submit new ticket

[fusiondesign]

Perfect. Now we know what causes it! I'll throw that into a common problems area somewhere.

[thekordy]

I think we should add some type of restriction on deleting a default status, default close status, default reopen status ... and I am thinking to begin working on transferring most of the settings from the file to the admin panel, may be in v0.3.0 or v0.4.0

[fusiondesign]

This config is growing quiet large for a config, I'd have to agree on the admin panel. Plus if we have an admin config table, we can control the IDs going in and out for default status via relationships.

[fusiondesign]

Added to wiki for now until 0.3 or 0.4:
https://github.com/thekordy/ticketit/wiki/Common-problems

[fishmad]

You could do a similar crud for language localizations, just not too sure what impact is would have on performance with all those extra queries - I did found a nice package that will scan files for trans() and automatically import these into the database for editing the text values.
https://github.com/barryvdh/laravel-translation-manager

[fusiondesign]

We can always Cache the database results for 1 month and make the "Save" button in the admin console flush the cache.

[fusiondesign]

This has the added benefit of migrations essentially allowing us to version control our config

[fusiondesign]

Welcome to the team btw Fishmad!

[thekordy]

I did found a nice package that will scan files for trans() and automatically import these into the database for editing the text values.
https://github.com/barryvdh/laravel-translation-manager

@fishmad It looks promising, We can give it a testing round and find if it integrates smoothly and if it is easy to use. then we can implement it in the same version with admin panel upgrade

We can always Cache the database results for 1 month and make the "Save" button in the admin console flush the cache.

@fusiondesign for the config settings, I think it won't be that much load as we can use only one query to load all settings, but I am not sure about the translation panel, does it load translations from database for front-end? or it just for translation modifications then it exports changes back to the translation files?