Perl Question (weird here, right?!)

[neenach2002]

Okay, I am working on a perl program that is basically everything-in-one. It lets you do billing, hosting, everything! So anyways, we are really interested in using Cerb4 as the backend/helpdesk! But our problem lies in pulling data from the database on the customer-end.

One option is using the PHP interpreter module for perl. Another is writing pure perl code to handle pulling everything from the database. In either case, we would have to build a custom support center, and probably couldn't use the one provided by you unless we developed a parser to parse the HTML output or something...

What encryption does cerb use on the password field? Is it MD5? If so that would simplify things a LOT...I guess I should just take a look at the database schema...

Just curious if anyone here has thoughts or suggestions...this is certainly something outside of what most people would consider the norm.

[neenach2002]

Okay, what we are going to do is not use Cerberus Logins at all. We will just have a mail form on our page that has the sender field as the email address of the currently logged in person. Then for their ticket history, we are going to pull the tickets for that address down into our app to display via a couple DB queries.

[jstanden]

Hey there!

Your later suggestion should work fine. The DB schema should change occasionally, but the address->ticket links are pretty fundamental and unlikely to change much.

For future reference, the worker logins are MD5 hashed right now in the 'worker' table. Ultimately they'll be salted on top of that, but they aren't at the moment.

The address (customer) logins are also MD5 hashed in the 'address_auth' table.

[neenach2002]

Thanks for that, thought it looks like we won't be using authentication for tickets (since the users have to be logged into our system to have an email address associated with their account). We will just be pulling down all tickets for their email address.

I do have a question, though. Why have the requester table at all? Wouldn't it be a little faster to associate each ticket with an email address directly? I'm sure the performance gain would be minimal as it's just one more query...(or maybe not an extra query at all, depending on how it is being done.)

[jstanden]

Hey there!

We do associate the original sender with the ticket directly (ticket.first_wrote_address_id).

But a requester is a many-to-one relationship, since additional requesters can be added to any ticket to also receive updates.

[neenach2002]

I don't think we will ever use multiple-requesters on a ticket.. However, this gives me an interesting idea. For our client dashboard, I think I am going to design it to have "My Tickets" (any tickets they are the original requester on) and then have another thing under that that says "other tickets" or something like that, or maybe have a link to display all tickets they are part of.

[jstanden]

Definitely!

We're probably going to do something similar with the official Support Center as well.

We may also allow the original sender to assign their own requesters -- but obviously that raises some concerns of situations where it's abusable. Perhaps adding a requester would send them an 'invite' link first.