Jump to content

DennisHermannsen

Member
  • Content Count

    574
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by DennisHermannsen

  1. Oh, I was under the influence that BootStrap 4 would get EOL'ed next year. Don't know where I got that from. I usually agree with you, but not on this one. There's lots of reasons to want to upgrade - in my case, there's a lot of cool new features for v4 compared to v3. v4 is built centered around flexbox which solves a lot of issues.
  2. And Bootstrap 4 is going to be EOL in about a year... It feels like they've thrown the new design together in a matter of days. I hardly doubt they started working on the new design before v8 was released - and at that point it would've been better to go with Bootstrap 5. The multi user function is actually pretty great. Not every client will need it, but a few of our clients will definitely need it.
  3. Wow... They really took the easy way out. I don't even know why I'm surprised. It's definitely progress, but this very minor change hasn't required much thought and is something I would have expected WHMCS to have released at least in 8.0.1. It just checks if a user is associated with any client, and if not, it allows you to delete it (and it just deletes the entry in tblusers). Why (oh why) didn't they allow us to force delete users. Why is there no API function that we can use to delete users? I foresee that automating stuff using the API will get more and more difficult in newer versions of WHMCS. Thanks for making at least some progress on this matter - but it feels like nobody from WHMCS sat down to read feedback in this thread.
  4. Oh boy... That does not match with #CORE-15257 as they told me. It's not going to be easy reading through change logs if the same issue can have 10 different case IDs.
  5. You don't delete the user - you delete the client. The DeleteClient function should have an option to delete the user as well (maybe just by passing 'DeleteOwner => True' with the function), and this would remove everything - both the client and the user. In that case, the user would no longer be able to login to manage any of the accounts the user was associated with. If you don't send 'DeleteOwner => True', only the client should be deleted, and the user would still be able to login to manage other accounts. That's how it works right now. Does that make any sense? I've not given it too much thought but I think that would work for most cases.
  6. I actually brought it up before September 29th. I also received this reply before that date: I took it as a "We're working on fixing this mistake" - and then the first GA release came shortly after.
  7. Isn't it the other way around? A client will always be a user, but a user will not always be a client. What I was initially suggesting was that the DeleteClient could have an additional argument passed to also delete an existing user with the same email address. It would solve the issue in our case since sometimes we want to delete everything, and sometimes the user would still need to access other clients' accounts. Thoughts on that?
  8. A hook could help - you just got to account for a lot of things.
  9. I bet there is, because it's a bit more tricky to know when you should delete a user account. There's multiple situations to account for - fx if the client only wishes to have their client account deleted but keep their user account so he can access other accounts they were invited to.
  10. WhmcsDetails is a thing for v8 - you can't use it with v7 or earlier versions.
  11. I've found something different. We started having a lot of uncaptured payments. All the uncaptured payments appeared twice in the Stripe Dashboard. It was not until yesterday where multiple new clients contacted us that I knew why.. Apparantly, the MaxMind Fraud module is marking random orders as fraud. The orders' fraud score is way below what we have configured the module to mark fraud orders by. Legit orders with a fraud score of 0.1 is being marked as fraud (when they should only be marked if the fraud score is 20+). All these orders is going to Uncaptured Payments in Stripe. Is anyone seeing the same as we do?
  12. @WHMCS John I think it's important that anyone from WHMCS gives an update on this issue. A lot of users would not expect important things to be broken in the third (production) release of WHMCS - and if you aren't aware of this thread, you most likely don't know that you're still keeping your clients' personal information after deleting their accounts. It's important that these things are adressed. There has been a single comment about this ~10 days ago from you, and no one knows if this is a thing that will ever get fixed. I reported the oversight to WHMCS support before the initial public release of WHMCS v8.0.0, and somehow someone still thought it would be fine to ship the update. Could you please make sure that someone gets back to this thread? It's not difficult to solve the problem either.
  13. I'm stoopid, I forgot a semicolon 😂 The following works, but it's probably not pretty to access the database on every email sent... <?php add_hook('EmailPreLog', 1, function($vars) { $templates = Capsule::table('tblemailtemplates') ->select('subject') ->where('name', '<Template Name>') ->get(); $return = []; foreach($templates as $names){ LogActivity($names->subject); if($names->subject === $vars['subject']) { $return['abortLogging'] = true; } } return $return; });
  14. I don't actually think it matters... It doesn't seem like the EmailPreLog hook is triggered when you use the SendEmail API 😂 Have you used it before with the API? Edit: Wait, does anything ever trigger it? I just tried with this code: <?php //Do not log emails for userid 2 add_hook('EmailPreLog', 1, function($vars) { $return = []; if ($vars['userid'] == 4) { $return['abortLogging'] = true; } return $return; }); My user ID is 4 - it still logs it. No matter if I send it using the API or send one of the default emails. The exact same code works for v7 - just not v8 🧐
  15. That could have worked if I was able to filter them based on message name, and not just the subject. The subject is not always the same 😅 Any other ideas?
  16. I need to be able to send the customer a unique token through WHMCS. I've created the email template and am sending the email using the SendEmail API. The only issue is that the email appears in the Email History - and that means that the unique code can be seen by anyone with access to the account (not great in case the account is compromised). I used to just manually add the email template to the 'user' category, but some recent update has made it impossible to send any emails from that category even though the response says success. Does anyone know of a way to send emails that won't be saved in WHMCS?
  17. Yeah, WHMCS should do their job. They use their own software - but I hardly doubt they would ever use the beta themselves. Heck, they don't even use v8 yet! They don't even have enough faith in their own software to use the latest version 😅
  18. There's UnblockIP from ServerPing: https://www.serverping.net/clients/cart.php?gid=3
  19. WHMCS v9 - Admin Area refreshed (3 blank spaces removed)!
  20. People have been asking that question for years, yet WHMCS never answers it. All WHMCS do is mention the feature request - but those feature requests are many years old and have hundreds of votes without ever being implemented. - https://requests.whmcs.com/topic/cancel-x-days-overdue-invoices Pssst.. You wanna hear a secret? That topic was also set as "Investigating" two years ago. It's not going to be implemented. https://web.archive.org/web/20180408220313/https://requests.whmcs.com/topic/cancel-x-days-overdue-invoices WHMCS tries to make it seem like the request system is really great and that everyone has a chance of getting their suggestions added - it only requires enough votes. Well, not only enough votes... They also need someone who actually cares enough to implement one of the most requested features for years.
  21. I'll have to stop you right there, John. The same thing goes for regular clients. In theory, you could just change their details. It's just a hell lot easier to delete everything than to have hundreds of inactive users (all with unique email addresses). ... And so can a client. But - if the client wants their account deleted, we should (and must) delete it. If a user (not a client) actually decides to contact us and asks us to have their account removed, why shouldn't we be able to delete it? Sorry, but I just can't wrap my head around why a 'Delete User' button and/or API function has been made. Reasoning? We're forced to delete data about a client if the client requests it. Not doing so is punishable with huge fines. In 2018, WHMCS made a lot of steps to make it look like they cared about GDPR - and then they basically ruined it with a single update and can't understand why we feel something is wrong. Please, please, please, please (!!!!!) let us know why it has now taken 3 releases (I reported it before GA) and there's still no solution to this. It's really just a matter of deleting the user the same way that a client is deleted. Sorry about my tone in this reply, my it really frustrates me. You can't make a release that is so GDPR focused back in 2018 and then ruin it two years later saying: "You know, you can just manually edit out the personal information for each user" - WE COULD VERY WELL DO THAT WITH CLIENTS AS WELL BEFORE 2018, It's just a lot easier NOT having to do that.
  22. Of course you shouldn't just go on a rampage and delete random users... You should only delete users that ask for it. Example: I am the owner of an account. 4 other are invited to access my account. I contact the company and ask to have my user account deleted. They delete only my user account - the 4 other users will still have their account, but won't be able to access my account as it no longer exists.
  23. I don't think I asked to be misunderstood, but I guess people can't see beyond the tip of their own nose... Let me rephrase in bullet points: It's very annoying that this hasn't been fixed This issue should have gotten more focus WHMCS should have given a statement about this issue instead of handling everything through tickets however: You can't just magically fix an issue without knowing why it happens I tried comparing our cases, and there's no common thread for the issue
  24. You should be able to delete different users. It shouldn't delete every user connected to a client - it should just delete the user that you select. That ain't hard.
  25. That's just not good enough. The account should be completely deleted. If a customer asks us to delete their account, we cannot keep any information about them. Everything has to go. It's very weird how WHMCS didn't even consider that keeping the email address and name would be an issue.
×
×
  • 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