@ahmed_badawy & @[deleted] We'll be pushing a new release today which will address the issue. For now, try disabling global variables.

thanx and waiting for it

where is it?

@ahmed_badawy & @[deleted] We'll be pushing a new release today which will address the issue. For now, try disabling global variables.

where is it?

Support Ticket System Offline

hi folks, thanks for the great job about osticket, we were waiting the new version with great spectatives...

We installed app from zip and git (both-os17-45b80f1) but in all cases get the same message: Support Ticket System Offline

Already activated the Online (active) status through SCP.

Could you give us any help about this issue?

thanks in advance, df

when will release the stable version, is there a specific date?

and thanx alot for your hard work

html

why you use text mail for reponse why not use hmtl mail to but example logo

progression graphe of ticket

is there a demo available? I can't seem to get it installed on my server, but I'd love to take a peek.

nice

I would just like to say at first glance 1.7 looks really nice, i know its still in developmet and more changes are underway.

@[deleted] is version 1.7 going to be compatible with php 5.3 and 5.4

also as a feature request i am sure i am not the only one it would be nice if users could login with email addresses and their own passwords, since if customers go back to the site they dont want to have to remember their ticket number to view their tickets or have to recheck their email to get their ticket numbers.

just a minor inconvience to some people.

+1 for using users email address for login.

I too would really love to see an individual client login that I can give and revoke access.

More on client logins...

I have had osTicket fully deployed now since the first of March. Prior to deployment, I had fully reviewed no fewer than 8 open source support ticket systems while performing test installs of around half. osTicket was the only one that was easy to understand and configure on my end, and, most importantly extremely easy to navigate from a customer perspective. Kudos to all the developers.

The application, as is, performs flawlessly as it is currently designed. I have no complaints on the existing 1.6 version. However, I do have one suggestion pertaining to client logins to make it easier on the customer/client side for them to be able to manage their support tickets. And, there is a very simple solution.

Currently all tickets are grouped by user and e-mail--quite nice, as access to one ticket provides access to all tickets that a user@emailaddress has opened. However, there is currently no way to effectively provide access to all tickets at a given client site to a client liason at the site. I did try to do this by creating a group called " Liasons." I have Departments created for each company, and the "Group" option allows me to restrict access to tickets by these departments. However, there is one simple element missing that would allow me to be able to create a "client" user with access to all tickets at their site as follows:

There are now five restriction options under the "Group" settings:

Can Create Tickets Yes/No

Can Edit Tickets Yes/No

Can Close Tickets Yes/No

Can Transfer Tickets Yes/No

Can Delete Tickets Yes/No

Can Ban Emails Yes/No

Can Manage Premade Yes/No

With the addition of one other option here:

Can See Internal Comments Yes/No

One would then be able to create a master client-user login, giving them access to all their site tickets by department, without giving them access to one's own proprietary information that one does not want a customer/client to see.

I believe that this would provide a whole new level of add'l functionality with a very simple update, probably for add'l purposes, other than what I've outlined here, as well.

Thanks!

Tim

Add'l on the immediate preceding post on client logins

Actually, you would probably want to set that option to be:

Can See/Post Internal Comments Yes/No

Or some permutation of the above, as you would create confusion if they could post internal comments that they cannot see. The above should cover the basics though at first.

If I'm missing something here, I'm sure someone will think of it.

Great news!!!

I'm diving into the new code right now, loving GitHub development tree... I think this way will be easier to help the project coding new features ;)

P.D.: anyone trying to make it multilang?

P.D.2: I know, I have two pending things for 1.6 and I am the worst :(

Great news!!!

I'm diving into the new code right now, loving GitHub development tree... I think this way will be easier to help the project coding new features ;)

P.D.: anyone trying to make it multilang?

P.D.2: I know, I have two pending things for 1.6 and I am the worst :(

I am looking at the code for 1.7 and, although I'm quite a noob, I find it quite a great learning tool....

So I have been considering exploring the use of gettext and poedit.... Perhaps it will speed up the translation of files, make the changes stick to general release and ease the burden of the real programmers, as they won't have to think too much about the translations.

Anybody else have this running? I don't want to step on toes and I certainly don't want to piss off the programmers who need to make changes on git like yesterday...

My kudos and congrats to everybody by the way... As I learn I might have too many questions, far too many.... or I might just faint when I realize I am not even knowledgeable enough to be even just a tiny bit dangerous...

When its final version 1.7 for production use is expected to release?

I want to upgrade my osticket soon... Please reply.

Thanks.

Great news!!!

I'm diving into the new code right now, loving GitHub development tree... I think this way will be easier to help the project coding new features ;)

P.D.: anyone trying to make it multilang?

P.D.2: I know, I have two pending things for 1.6 and I am the worst :(

I'm also looking for an opportunity localize product to Cyrillic, tell me how true test is done?

Running 1.7 DRP3. Upgraded from DRP2. The upgrade failed though. First it tried to use the database table ost_ticket_thread which didn't exist. After running it again, I got forward but complained because the sub argument returned more than 1 line, which I was able to resolve by deleting the staff members. Since this is just a test thing for us now there was no data in the databases of anything of value, so I just blew it away and started it fresh with DRP3.

I get this error if I select the default email template.

-------------

Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is = illegal if there is no GROUP BY clause