Jump to content

Shardhost

Members
  • Posts

    13
  • Joined

  • Last visited

Posts posted by Shardhost

  1. For those having issues with ticket status values matching up, what are the results of the following query on your WHMCS db?

     

     

    SELECT status, COUNT(*) AS total FROM tbltickets GROUP BY status

     

    Note, the 'total' values don't really matter, but would be good to see in contrast to what's you're seeing in Blesta.

     

     

    +----------------+-------+

    | status         | total |

    +----------------+-------+

    | Answered       |    10 |

    | Closed         |  1295 |

    | Customer-Reply |     2 |

    | Open           |     1 |

    +----------------+-------+

     

    Blesta --> Open (1308)Awaiting Reply (0)In Progress (0)

  2. Tickets should come across with an equivalent status as in WHMCS. Here's the mapping, on the left are status values in WHMCS, on the right are their status values in Blesta. If a ticket has a status not listed on the left Blesta marks it as "open".

     

     

                'Open' => 'open',
                'Answered' => 'closed',
                'Customer-Reply' => 'awaiting_reply',
                'Closed' => 'closed',
                'In Progress' => 'in_progress'

     

    This does not appear to be working then:

     

    Blesta --> Open (1308)Awaiting Reply (0)In Progress (0)

     

    WHMCS --> Closed (1293) Open (1) Customer-Reply (2) Awaiting Reply (3) Answered (10)

  3. WHMCS doesn't properly account for client credits. They can be created without reference to any transactions. Blesta doesn't allow this, so when credits are imported they are inserted as transactions with today's date.

    That really wouldn't surprise me.  

     

    Is there a fix to close all tickets?  Couldn't see anything while poking around.  I really like the way that Blesta handles transactions. 

     

    Kudos to you guys for coming up with this importer.  I've used or attempted to use importers from competing products and it either required a massive payment for 'custom coding' which I am sure was already done, or an importer that required a significant amount of manual keying and fixing of merged orders.

  4. I'd be "moved over a lot faster" if this thing was actually designed properly. I'm sorry, but this is just utter garbage.

    20 minutes, then it dies. There's no reason this script should take 20 minutes to run. There's no reason it should die after 20 minutes. Hell, max_execution_time isn't even an option in php 5.4, though oddly enough it still shows up in phpinfo. That thing is so high it's insane.

     

    I'm done wasting my time and my money here. Call me when this thing actually works and I'll consider paying for it, but, as it is, this is total garbage. If you can't even get an import script working, then how am I supposed to trust your billing system?

     

    Ensure your web server is not overriding PHP's max_execution_time.

×
×
  • Create New...