Jump to content

steven99

Member
  • Content Count

    979
  • Joined

  • Last visited

  • Days Won

    24

steven99 last won the day on December 6 2021

steven99 had the most liked content!

Community Reputation

132 Excellent

6 Followers

About steven99

  • Rank
    Level 2 Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Remove the "return;" sitting all alone before all the fun starts. You are basically stopping the rest of the file from executing with that there.
  2. Not at the invoice level, but perhaps at the gateway level if you use a custom gateway with support for this specific use case.
  3. I would bet you have Automation settings -> Client Status Update -> "Change client status based on active/inactive products" or "Change client status based on active/inactive products and not logged in for longer than 3 months" set and you just never noticed the inactive ones until now. Disabling registration without ordering prevents this behavior or at least they have to go through order processing and thus fraud checking.
  4. Well, again, you would need an addon module and some hooks -- done by a PHP developer. Just hooks could do it but a module allows for options. Basically using the AdminLogin hook, a session variable containing the current timestamp for example is checked for and if exists then the session is reset and if it isn't set, it is set to the current timestamp or what not.
  5. Would need an addon module to track the "active" session and hooks to block the other sessions.
  6. There are a lot of changes from 7 to 8 and depending on what version within 7 will make it more or less so. For payment gateways, that changed to payment methods and having to conform to that with multiple payment methods being available. Gateways methods themselves are the same but adding to the WHMCS client are different and for token gateways the gatewayid is no longer used.
  7. You can use AcceptOrder, get the order via API, iterate through the order items and each should have service id . Tthough don't recall right off if order items have service ids and if not you can get the invoice and the line items there do have the service ids.
  8. Not sure I understand what you mean. All API code should be within PHP and none should be visible to the client . If, however, you mean you're adding PHP to template (.tpl) files and enabling smarty PHP handling, then you are barking up the wrong tree. You should be following the MVC dev pattern of having a Model (database item object - not strictly required in WHMCS case), View (template files), and Controller (where actions are handled at). No logic (PHP) goes in to the view part of MVC and the most that should go there is like ifs, loops, etc to get the info to display in a pretty way. Have a look at the sample provisioning module for a basic example of MVC server module. If you have not dealt with MVC before, I would recommend to read up on it to get the basics. As an aside, the provisioning / server modules don't actually require a server. I prefer to call those service or product modules because of this fact. So for example, you could have a server module that's only job is to check the weather and output that to the client when viewing the service details.
  9. Use the ClientAreaFooterOutput hook for that .
  10. You'll want to send the verification email and check mail logs to see if it actually hit the mail server and was sent out. When mail issues come up, mail logs should be one of the first places to look while troubleshooting. As for the tracking of sending the verification email that can be done via a EmailPreSend hook and at least add a log entry: <?php add_hook('EmailPreSend', 1, function($vars) { //Email verification logging if ($vars['messagename'] === "Email Address Verification" ) { $results = localAPI('LogActivity', ['description'=>"Email verification message sent", 'clientid'=>$vars['relid'] ]); } }); NOTE: The message could still hit this hook and say it was sent but another hook could cancel it afterwards and the message could still have not sent due to SMTP issues.
  11. The IDs in that column are service IDs and not order IDs. On the client summary page, hit View Orders and it will show all orders for a client and the ID column there is what you would use for that API call.
  12. What is the end goal? That is, do you want to delete just so you / the client doesn't see those services in lists? There isn't an API call for that and so would have to be some internal call if it can be found. Though, if we are just concerned with the service, I suppose deleting from database model may work. That will leave orphan entries around in like tickets, invoice item entries, and other such places that services were selected and that may or may not cause issues. Instead of deleting records, using a hook for at least the client side to hide those services would provide the same result. I am sure there is a hook laying around here somewhere that would work still. Admin side would be a bit more of a challenge because not as many hook points and areas you can tweak.
  13. An output hook with javascript to inject the note element in to the proper location would be needed for this. Didn't see a hook right off that might fit this exactly, so a clientareapage hook might be needed and then filtering down to what template file was used.
  14. That is pretty common no matter what it is unless it impacts them in some fashion in their day to day and they have to watch for it.
  15. To answer your question, yes it can be done in WHMCS and nearly any other service / recurring specific billing system out there. For this you just create a simple recurring product with no server modules, a bunch of configurable options, service custom fields, etc that details the contract and contract it self and you have a recurring invoices with a help desk.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated