Jump to content

srn

Members
  • Posts

    31
  • Joined

Everything posted by srn

  1. srn

    High Availability

    Out of curiosity, does anyone have recommendations on deploying blesta in a high availability (HA) configuration? As long as database updates aren't required we believe we've figured out how to do atomic updates between two versions on a single machine while nginx is running, but due to the licensing we aren't sure if it's possible to go beyond beyond a single machine. For example, I don't know if two licenses on two different machines and a single database would work.
  2. Paypal is no longer refunding the 2.9% commission - please vote for this feature at https://requests.blesta.com/topic/manage-paypal-subscriptions
  3. Sorry, missed this - yes one of our customers found it for us. We applied the workaround and are no longer experiencing issues.
  4. If "Allow users to modify current and create new subscriptions" is selected in "Manage PayPal Payments Standard", meaning that the value of "modify" passed in the paypal form is 1, then paypal reports an error. The workaround is to deselect "Allow users to modify current and create new subscriptions" so that the value of "modify" is 0. Please see https://www.paypal.com/us/smarthelp/article/important-notice-regarding-upcoming-subscription-changes-ts2239
  5. A customer pointed out to us that blesta's labeling scheme is not friendly to older versions of google authenticator in that the issuer is not included in the label, see https://github.com/google/google-authenticator/wiki/Key-Uri-Format#label
  6. Thank you. In reference to CORE-1686, is there any circumstance under which both issuing a credit for unused time and voiding invoices that are not yet due would be desirable? If not, the choice should probably be a drop-down and not individual check boxes. Also, is there any rough estimate of when 4.0 will be released? Are we talking weeks or months?
  7. Actually, to be completely honest I didn't really expect a credit to be issued, but my understanding from talking to support was I should file a bug report. Sorry for the noise if there wasn't really supposed to be a bug report. Assuming it's a new feature and not a bug, I'd like to hear if there's a way we could implement this for ourselves that could contribute to a more general release.
  8. I commented on this feature request thread: http://www.blesta.com/forums/index.php?/topic/588-cancel-reason-account-credit/ asking about the status of the feature request " Configurable credit for remaining time - if a client cancels with 25 days left, I'd like to issue an account credit for the remaining amount." The response back from Paul (on your staff) was "Settings > Company > Billing/Payment > Invoice and Charge Options: Allow Prorated Credits to be Issued for Service Downgrades". That's why I expected a credit to be issued for the canceled service.
  9. This API call generates a credit (ripped from our python interface) call("POST", "Services", "edit", {"service_id": 65, "bypass_module": True, "vars": { "prorate": "true", "status": "canceled", "date_renews": "2016-05-06" }}) This does not: call("POST", "Services", "edit", {"service_id": 66, "bypass_module": True, "vars": { "prorate": "true", "status": "canceled", }}) This does not: call("POST", "Services", "cancel", {"service_id": 67, "vars": { "use_module": False, }})
  10. Here is my bug report then http://www.blesta.com/forums/index.php?/topic/6433-canceling-service-does-not-result-in-a-credit/
  11. Following the same initial process but changing the renewal date to be one day after the creation date (instead of canceling) results in a credit of $5.00. At some point I got a credit of $5.17 instead of $5.00 but have been unable to reproduce the result.
  12. With blesta version 3.6.1, from the admin interface: * Under Settings->Company->"Billing/Payment" ** Ensure "Allow Prorated Credits to be Issued for Service Downgrades" is enabled for the given client group ** Disable "Automatically Apply Loose Credits" (only to simplify expected and actual results) * Under "Clients", create a test client that has "Total Credit" 0.00 and "Total Due" 0.00 * View test client * Click "NEW SERVICE" under "Services" * Select package that recurs and costs money and click CONTINUE * Select "Create Invoice" . Select "Active" for status though this may not matter. Any term greater than one-time and amount greater than 0.0 should work. I created a service with a 1 month term @ 5.00. * Click "ADD SERVICE" * Observe client has Total Credit 0.00 and Total Due $5.00 (or whatever the price is for the initial term) * Select "Manage" for the active service * Under actions, select "Cancel" * Click SAVE under Actions Expected result: Total Credit of 5.00 and Total Due of 5.00 Actual result: Total Credit of 0.00 and Total Due of 5.00 Distribution: Ubuntu Trusty 14.04 php version: 5.5.9+dfsg-1ubuntu4.16 mysql version: 5.5.49-0ubuntu0.14.04.1
  13. While https://dev.blesta.com/browse/CORE-590 exists for the cancellation reason, canceling a service currently doesn't prorate. I'm assuming it's still a new feature since nothing about proration or credits appears in the Services::cancel method. It looks to me like just calling prorate won't always work because prorate won't do anything if an override_price is set.
  14. No, it's not possible for the client to update the auto-payment date, at least our customers tell us they can't. It looks like start_date is accepted as an option for buildProcess. Couldn't this be set to the one day before the next service renewal? I believe a combination of the first and second trial period could be used to exceed the 90 day limit, given the second trial period is not used right now.
  15. It would be good if the paypal subscription for an invoice associated with service(s) could be set to the day before the next service renewal date. Right now, it appears that the next subscription payment happens $term days after the payment date regardless of when payment is actually due.
  16. I think that could be because it's obvious in the UI how to disable two-factor authentication. That says nothing about how the administrators decide to disable it for a customer. Right now you're requiring everyone to devise their own procedure, which in the common case is probably asking for easily available information, like physical address or phone number. This is less secure. The method we chose was to define 1. preferred contact method client field 2. optional reset passphrase client field and 3. a contact type, but by default we aren't able to enforce that being configured before two-factor authentication is enabled.
  17. Backup codes or the like are incredibly common. Even google does it: https://support.google.com/accounts/answer/1187538?hl=en I would much rather have such a feature baked in rather than having to procedurally kludge it in, which is what we have now.
  18. It looks like with the current code base, (un)suspension notices only go to the primary contact. Most likely other contacts, such as the billing contact, are going to care that the service was suspended. I think the best long term solution would be to be able to select from a list of defined contact types where the suspension notices go, probably from the same place where the email template can be edited. In the meantime, attached is a patch that sends the notices to all contacts.0001-By-default-un-suspension-emails-are-sent-to-the-prim.txt
  19. We've now had multiple people who have been unable to pay because they didn't understand the paypal buttons were buttons. So +1 to this if it gets buttons that say 'pay with paypal' on them. For now I edited it to be https://www.paypalobjects.com/en_US/i/btn/btn_paynowCC_LG.gif
  20. We had payment reminders off on accident, and now we want to send them. It is important to us because we want to send a certain number of reminders before suspending a service. If only a single reminder of the three is enabled and that kludge is only in place for a single day, it shouldn't result in duplicates, correct?
  21. A simple notice for the actual cancellation would be sufficient. Anything is better than nothing. Maybe Hi {contact.first_name}, Your service {package.name} - {service.name} has been canceled.
  22. As a temporary workaround, would setting if ($invoice_reminder_datetime == $todays_datetime) to if ($invoice_reminder_datetime < $todays_datetime) for one run do what we want?
  23. As it stands, payment due reminders are sent IIF the current date matches the exact date: if ($invoice_reminder_datetime == $todays_datetime) This will lead to missing payment reminders if the job was turned off for whatever reason. It should be possible to send the payment reminder if todays date is greater than the datetime, either by keeping track of whether the given notice (notice1, notice2, notice3) has been sent for the given invoice, or as a manually selected task.
×
×
  • Create New...