Dead or alive? - Continued...

[joeleo]

+1 for using users email address for login.

[mandbaudio]

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

[tpleiman]

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 "<client-company-name> 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

[tpleiman]

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.

[anavmon]

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

[gcontreras]

Originally Posted by anavmon

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...

[shitansh]

When its final version 1.7 for production use is expected to release?
I want to upgrade my osticket soon... Please reply.
Thanks.

[toFlash]

Originally Posted by anavmon

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?

[mbazdell]

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.

[davidlee]

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

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

[SELECT tpl.*,count(dept.tpl_id) as depts FROM ost_email_template tpl LEF= T JOIN ost_department dept USING(tpl_id) WHERE tpl_id=1]



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