HiSo I decided to create a small auth page before a I let my clients open new tickets on this system, problem is i would like to get (POST) some vars from my auth.php page to a new ticket, (email address is the only one I can think of now).can anyone here tell me how and where to look ?Noam

user information is stored in ost_users.

7 days later

Thanks ntozier, for your response.I looked into the ost_user table, and the data it holds is not enough for me.lets say, I have my own authenticated users db with, a bunch of user info stored in it, i would like to fetch this data upon user login, and place some static fields (with this data) in a new ticket form. somthing like this.any ideas?

You can configure additional fields at Admin panel -> Manage -> Forms -> Contact Information.  However that increases the number of tables that you will have to query to rebuild that information to be workable.  While not an exhaustive description this article will tell you how to do the phone number.  http://tmib.net/how-manually-update-clientuser-phone-number-osticket-181xIt would then just be a matter or figuring out the rest of the fields that you customized.

I'm looking into that right now.Thanks ntozier.

Very welcome! :)Although I do feel that I should warn you a little that you might want to read: http://www.forum.osticket.com/d/discussion//upcoming-osticket-feature-user-accounts-includes-commit-notes-and-dev-q-a

I just read it, you're right, this document encapsulates all that i need pretty much,-user auth-user special configurations (I also got that between the lines)so I'll be more than happy to upgrade. when is the release predicted date?

I think that there will be a developer preview release (DPR) out in the next week or two.  After that I imagine that there wil be a release candidate (RC) or three before a stable (ST) is released.

2 months later

just upgraded. works ok, few bugs still pending.

IMVHO it could be smart to "outsource" the whole authentication (both users and staff) to a plugin. By default it would use the internal db, but it could "easily" be replaced by another data source (any kind of external DB).This way it could always fetch fresh data when needed, w/o risk of being out of sync.

Write a Reply...