Chris74

I'm right. API tokens on their own present a serious security risk. Anyone gaining access to this unprotected, simple text file will gain full root access. On it's own, the API token is far less secure than using a simple encrypted password. I don't believe WHMCS understand that you need more than just the token on its own. There should be multiple separate layers of security in place. It should also be mentioned that cpanels "API Tokens" are not tokens - it's just an API key. It doesn't expire or change and It isn't used to authenticate. See this... https://nordicapis.com/why-api-keys-are-not-enough/

This may be a really dumb question but I'm a little confused about something relating to the use of the API tokens in the server setup. Correct me if I'm wrong, but the idea of using the API tokens instead of a full root password is that it provides more security, so that WHMCS can only perform the tasks it needs without having full root access. If I want, I can configure all our servers in WHMCS with the root username and password and it will perform all functions needed - but I'm taking a risk by doing that. So using the API token with only certain privileges would seem to be a sensible solution. The problem I'm having is with the "Login to WHM" button on the server setup page. When using an API token, I have not provided the root password, therefore any connection made by WHMCS should only be allowed to perform the functions listed in the API token - however, I can simply click this button which will send me through to any server where I will have full root access, seemingly negating the need for tokens and privileges. A username must be provided - WHMCS won't connect to a server using a token unless a username is provided. So if the root user is specified, I assume this simply allows full root access anyway. I assume this is due to the privilege "create-user-session" being set - which could be just as powerful as having the root password anyway - in fact, all a token needs is that privilege, to allow anyone root access in a single command, simply by specifying the root username. As tokens are not stored encrypted, doesn't this make the use of tokens less secure than using a password, which is encrypted in the database? I don't really want to pass through to WHM from WHMCS - so perhaps I can remove "create-user-session" without this affecting the functionality of the cpanel module?

Yeah you're right, it does exactly what I want it to. I didn't know there was such a comprehensive reporting function in there. Never spotted it before. Thanks.

Hi folks, I would like to create a report that includes the total from paid invoices where VAT has not been charged. It should work on the date paid field. As we are in the UK, we charge VAT at 20% to our resident customers, which makes up almost our entire customer base. We don't charge VAT to customers outside Europe. The way our accountant calculates VAT payable is on the gross income from transactions, with the VAT MOSS data taken into consideration. Until now, I haven't tried to identify the non VAT transactions, so we've been paying a bit more VAT that necessary. I need to identify for any given month, the total income from paid invoices that is not VAT-able, so we do not have to pay VAT at 20% on these invoices to the government. It won't be much, but I want to make sure it is correct - and we can also claim for the last four years. I'm not a developer so this is beyond my expertise so will gladly pay a fee. Many thanks.

Hi, I'm looking for some advice relating to the nextinvoicedate field in the tblhosting table. A while back there seemed to be a problem with the cron jobs causing very high load and taking a long time to process. I noticed some issues with some hosting plans suddenly having the next due date of the year 1999 or 2000. Very strange. We resolved the handful of products with that problem. It would appear this is not the only issue caused. Some customers are contacting us saying that they haven't received an invoice for their renewals. They only become aware that they are overdue when the account is suspended for non payment. (Personally I think this problem has been related to Modulesgarden's "Hosting renewals" module.) There have been no problems with the domains table. Anyway, so I look in the database and I find over 800 products that have the nextinvoicedate field set to 0000-00-00 - which is most definitely the cause of this issue. WHMCS is not generating invoices for these products (as you'd expect). So my questions, if anyone would be so kind to help.... 1. Does WHMCS always store the dates in the database as yyyy--mm-dd regardless of the date format chosen in the config? 2. Why would all of the due dates on all of the products get updated daily? Is this something that WHMCS does, or should I be looking at a cron hook within an addon causing this? 3. Could someone please be so kind as to offer me the correct syntax to set any "nextinvoicedate" that is currently set to "0000-00-00" to the same value as the "nextduedate" in the tblhosting table? Thanks very much in advance for any help you can offer.

A client just upgraded his plan and was invoiced with VAT in the normal way. Then he decided to downgrade back again almost immediately. He was credited, as we have that option enabled in the settings. I checked his credits and noticed that the refund did not include VAT, so he was 20% out of pocket. I also found this thread from 2014... I don't know if this was fixed at some point and then re-introduced in a more recent version (I'm using 7.6.1) or whether WHMCS decided there was some reason not to include VAT on downgrades and didn't fix it.

Ahh yes, in the Miscellaneous section there are two options that will set a client to inactive - Change client status based on active/inactive products and Change client status based on active/inactive products and not logged in for longer than 3 months I think it might be a good idea for WHMCS to highlight this in their documentation since they introduced the new customer retention option. Prior to this, it makes sense to set the status of any account to inactive if it has no active products or domains - but since they introduced it, any new client that hasn't yet purchased anything will get deleted within 24 hours of signing up! Hope this is useful for anyone else who finds themselves in this situation. Just switch to the option - Change client status based on active/inactive products and not logged in for longer than 3 months and that will prevent it happening.

It seems that since 7.5 the cron designed to delete inactive customers is also deleting new customers that have had no activity. We asked a client to create an account so she could take on a service from someone else. We couldn't find her account but she showed us a screenshot of her welcome Email showing she did indeed create one. I checked the logs... 25/09/2018 08:06 Client Deleted - ID: 10278 System 24/09/2018 09:47 Created Client redacted - User ID: 10278 System Our daily cron runs at 8am, so I can only assume that the account was deleted due to inactivity. We have the automation option " After no invoice or transaction activity has occurred for the following number of months: " set to 72 months - but I think there may be a problem with the way this is calculated and it might also include accounts that have never logged in. Its possible she created the account, received the Welcome Email and never logged into it. Perhaps if she had, the account wouldn't have been deleted. I wonder if anyone would mind seeing if they can reproduce this.

I don't agree and I don't think WHMCS should assume anything. There's too much hard coded "assumption" built into WHMCS that we can't change. I'd like the flexibility to allow the client to set the auto renewal period per domain whenever they want. That way, after the initial renewal, they could reduce or increase it as they liked. I suppose it's actually very simple to implement too. Just one field to update. If we put the decision in the hands of the client - it's one less thing for us to worry about.

Yes, that goes without saying. I suppose what I meant was that I'd prefer WHMCS not to remember the registration period from the first order at all - and default the auto renewal period simply to 1 year. As you say, the client can always add years to the registration manually whenever they want to. It would be very restrictive to reduce the maximum registration period down to 1 year. My main point is that it isn't common sense to assume the customer will want to renew their domain for the same number of years they originally registered it for, so WHMCS should really consider providing an option in the general settings to effectively disable this behaviour and assume a 1 year renewal period for auto invoicing. Yes I'm using it and I completely forgot that this was hooked into the daily cron. What I did was to run the /modules/addons/resellerclubmods_tools/cron/resellerclubmods_dompricesync.php cron to update the prices after I'd made some changes to our domain pricing - I noticed that the client pricing didn't get updated. I thought incorrectly that the dompricesync.php would do that - but it's actually a different process that handles this. So after all this, I realise now that all I need to do is force the daily cron - or just wait until tomorrow!

Yeah I've just seen that auto price calculator module. I tried the demo but got an access denied error. Can't believe there's no simple way to do this in WHMCS. It should be built in. I also don't agree with the way WHMCS stores the original number of years registered and invoices for that same period on renewal. It's reasonable to assume that you might reg a domain for an initial period but not want to renew it for the same number of years the next time. I think the default auto renewal "registration period" should be set to one year and then clients can always add as many years as they want manually. It seems the wrong way around to me. The other alternative would be to allow the client to set the auto renewal period themselves. Ideally, I'd like an option to fix the "registration period" to 1 year on all domains after the initial registration - or to completely disable this functionality - then (most importantly) I'd like an option to synchronize the domain prices with the current pricing in the tld config. I might get a 7 day trial of that module and see if it's any good.

Is there a better option than the "Bulk Pricing Updater" for keeping the prices of clients domains updated? Now that we sell dozens of different domain types, this tool is very difficult to use. Each tld you want to update has to be selected manually and the price entered manually - for each number of years. With 250 tld's that's 2500 individual price changes! Is there any other way? We pay for our domains in USD and sell in GBP. Domain prices are synced daily from the registrar into the WHMCS configuration - and can change regularly. That works fine for new registrations and manual renewals - but I would guess that any domains set to auto renew will be invoiced at the price the client paid when they purchased the domain (or whatever is showing in the client's account for each domain). I want to update the clients individual domain prices automatically to match the main prices in the TLD configuration. I'm astounded that there doesn't seem to be any way to keep these synchronized.

You've not properly explained how it works. I'm more confused now than when we started this conversation. Either way it all looks far too complicated. I like the way in WHMCS a client can enable or disable auto renew for a domain but still have the option to manually renew whenever they like. It works great. All I really want is the same option for hosting plans too. I think your addon has some great features but we wouldn't use most of them - and I'm sorry if this sounds unfair, but I've asked you some pretty straightforward questions and your replies just don't make any logical sense to me, so I don't think I could use your module. Thanks for your time anyway.

Really? That doesn't make sense at all. If you choose not to automatically renew something. It doesn't mean you don't wish to renew it. The client may want to renew the product manually. Do you not differentiate between automated and manual renewals? The client may also wish to renew their domain automatically, but not their hosting. In your above reply you said... Did you really mean that? Simply switching off automated renewals will do that for a domain (even f you don't want to?) and cancel the associated hosting service? Where is the logic in that? Domains and hosting are entirely different and should be independent. It looks like you've actually managed to make WHMCS even less user friendly and reduced the functionality of the auto renew process by a long way. How can you call it "enhanced" renewals when you've made it more restrictive?

Thanks for your detailed responses. I'm sorry but I'm still unclear about the reminders. Can you confirm that a client will still receive reminders to renew, even if auto renew is disabled for a service?