Jump to content

SSy

Members
  • Posts

    74
  • Joined

  • Last visited

Everything posted by SSy

  1. Okay I will test accordingly and let you know if this is how it is functioning.
  2. This is what my settings page now looks like. Based on this, my understanding is as follows: 1) If a service started on January 4th, it will renew on February 4th and March 4th assuming it is monthly billing. 2) They will be sent an invoice on the 2nd of March, and that invoice in the blesta panel will say it is due on the 4th but invoiced on the 2nd. 3) If they fail to pay by the 11th, their service will be suspended. Yes?
  3. Well I've updated it in the company settings and ensured that the client group uses the company settings. It still has not fixed. As I am paying for the software and cannot locate the issue, please advise.
  4. So which option should control the space between the invoice date and due date?
  5. Have confirmed this is server wide - all invoices are now being given only 2 days before suspension after the invoice instead of 5. How do I fix this setting?
  6. Further investigation indicates this: 1) All previous invoices were created on the same date: 23rd of the month. 2) All previous invoices stated the due date was on the 28th of the month 3) This last one magically shifted to the 25th of the month for the due date. 4) The setting in the control panel says "Invoice Days Before Renewal" = 5 days Therefore for some reason the system is suddenly for some reason making the due date 2 days after the invoice for some reason. Any advice?
  7. I have checked the logs and it appears an invoice was created on the 25th of Feb instead of the 28th which is when the payment is due. How do I fix this bug in the date? Our server experienced a crash recently so it is possible something got messed up in that.
  8. One of my clients who is using PayPal payments was automatically suspended a day before his invoice was due, even though the system is set to only suspend services 2 days after the invoice is due. Any idea why this has happened?
  9. A client of ours has notified us that their account was cancelled via Blesta. I can see in the logs that a request was sent to WHM to delete their account. Their billing is all fine and I can see no reason for the cancellation. The only possibility I can see is that they did it themselves, which seems unlikely. How do I reverse this? In actuality, it seems the client may have cancelled and is playing games. How can I determine if they initiated the cancellation? Is there a note of this in the log?
  10. SSy

    7 day trial account?

    I'm not going to be upgrading yet due to custom code implementations, but is there a mass mailer for pre-4 that I can use?
  11. SSy

    7 day trial account?

    Hey there - yes, I mean for clients. I can't see that plugin, or the mass mailer plugin, for example, in my plugins list. Is there somewhere I can download it?
  12. SSy

    7 day trial account?

    Does Blesta have a mechanism for trial accounts?
  13. Has anyone successfully implemented a mechanism for either the standard or universal module to cancel subscriptions? Any code snippets that I may use as a start to get this added to the module?
  14. Determined the issue arises if you have 'subscription only' selected in the PayPal payment gateway settings. However, I'm confused - if someone upgrades their package, shouldn't Blesta cancel the old one and create a new one with a prorated difference? That's what a previous CP i was using did. The way it currently works it seems to just get a one time payment for the difference and leave the original subscription running.
  15. Upon further investigation it appears to be a bug with the PayPal module: switch ($this->ifSet($this->meta['pay_type'])) { case "both": if ($recurring_btn) return array($regular_btn, $recurring_btn); return $regular_btn; case "subscribe": return $recurring_btn; case "onetime": return $regular_btn; In this case, it is set to 'subscribe' but the recurring_btn variable is not set because the $recurring_fields variable is never set. This is when trying to upgrade a yearly package. I have added this code above the snippet above as a temporary hack: if (!$recurring_btn) $recurring_btn = $regular_btn; Please advise on an actual fix for this issue.
  16. Upon further investigation it appears the 'gateway_buttons' variable is not being set properly by the PayPal module. When I var_dump the 'gateway_buttons' variable I get this: array(1) { ["paypal_payments_standard"]=> array(0) { } } Any clue how to get this populated with the correct button?
  17. Hi there - currently when a user signs up they go through the checkout and there is no problem - the paypal payments link shows up. But if they try to make a payment for an outstanding invoice, they get to the 'Confirm payment' page but there is no link to make payment. It just says their address along with 'PayPal payments standard', and a button to 'Edit Payment' on the bottom. Any advice on how to enable the PayPal payment button?
  18. Thanks Paul Another question - say a customer signs up using Stripe to pay and his account is setup as auto-debit. If we disable credit card payments afterwards, will Blesta still keep charging them as per their original payment or will it then ask them to pay using one of the active payment methods?
  19. So stripe supports subscription payments and I tested an order but it did not create one - can I then assume that Blesta automatically charges the credit card on file every month if it is a monthly subscription? I know with PayPal it creates subscriptions, so I just wanted to make sure the client does not have to manually pay every bill using Stripe (assuming they checked save credit card information)
  20. Yeah, gone with an AJAX solution since navigating Blesta's internal structure is far too complex for such a small task
  21. I don't know what a token field is - I just want the form to submit to itself and deal with it strictly on the page with php.
  22. Hi there - I am totally alien to the way Blesta seems to work from a backend standpoint in regards to workflow. Regardless, I have create a custom contact page in my template, and created a form that submits to itself. However, whenever I click 'submit', despite the fact that the form is supposed to submit to the same page and get processed on the same page, I'm getting the following error: Files does not exist: /home/domain/public_html/domain.com/plugins/cms/views/client/custom/message.pdt on line 120 in /home/domain/public_html/domain.com/lib/view.php Printing Stack Trace: #0 /home/domain/public_html/domain.com/lib/controller.php(197): View->fetch('message', 'client/custom') #1 /home/domain/public_html/domain.com/app/app_controller.php(0): Controller->partial() #2 /home/domain/public_html/domain.com/app/app_controller.php(0): AppController->setMessage() #3 /home/domain/public_html/domain.com/app/app_controller.php(0): AppController->verifyCsrfToken() #4 /home/domain/public_html/domain.com/plugins/cms/cms_controller.php(14): AppController->preAction() #5 /home/domain/public_html/domain.com/plugins/cms/controllers/main.php(17): CmsController->preAction() #6 /home/domain/public_html/domain.com/lib/dispatcher.php(102): Main->preAction() #7 /home/domain/public_html/domain.com/index.php(66): Dispatcher::dispatch('/contact') #8 {main} Why is it trying to fetch a 'message.pdt' when all I am doing is submitting the form to the same page? I don't want Blesta to react to it at all and just let the process go on its own.
  23. Hi Naja, Thanks for that - I have removed the button, but even so, if a client were to get creative and manually type the url in using an active account's modify link, they could still do this same thing. The repercussions of it happening are so great and my penchant for automating what I can makes it quite necessary to nip this problem. I will look into your plugin, thanks.
  24. Can you provide the file location of the fix so that I can manually apply it on my end? I've customized a lot of aspects and would rather implement it manually than risk losing other changes through updates.
  25. Hi Paul, I can't log in or respond on the bug ticket you created on that other site, but I have this recommendation (let me know if it is likely you will take it otherwise I will start coding it myself): Add an optional function in Blesta that is disabled by default, but allows administrator to enable. The functionality is as follows - When a client service is being provisioned from pending to active, Blesta checks to see if there is another pending service with the exact same domain and exact same username, on the exact same server. If so, it will automatically delete that service (without using the module) and void its associated invoice. The current mechanism that creates invoices and pending services for each checkout attempt is both odd and confusing, especially for customers that come back to their account. This will nip a lot of that and minimize the administrative efforts users have to expend to cope with these redundant things. It will also remove the possibility of this bug happening.
×
×
  • Create New...