srn
-
Posts
31 -
Joined
Posts posted by srn
-
-
-
Paypal is no longer refunding the 2.9% commission - please vote for this feature at https://requests.blesta.com/topic/manage-paypal-subscriptions
-
On 5/1/2019 at 2:51 PM, Paul said:
PayPal reports the error when the client tries to make any payment, or when the client tries to set up a subscription? Are you experiencing this now in the live environment? Thanks for the link.
Sorry, missed this - yes one of our customers found it for us. We applied the workaround and are no longer experiencing issues.
-
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
-
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
-
-
I see. A feature for a prorated credit on the remaining service term upon cancellation would have to be added. This wouldn't be tied to the existing service downgrade credit.
I created CORE-2200 for this feature and detailed what I think will need to be done to make it happen. If you were to do it yourself in a way you intend to share, it may be best to do it on version 4.0 of Blesta since essentially every file has changed.
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?
-
That's why I expected a credit to be issued for the canceled service.
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.
-
Why do you expect a credit to be issued for the canceled service? A service cancellation is a removal of the service. A service downgrade would be a change to the term, period, renew date, or service options that result in a prorated price change whose total is less than zero.
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.
-
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,}}) -
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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
-
No, I believe that would result in duplicate notifications.
There is no internal tracking for whether a particular notice has been sent out, so if the cron does not run for an entire day, the notices that should have been sent that day will never be sent. More critical tasks like invoice generation or auto debit, etc will occur when the cron next runs.. but late notices are not in that category.
Is it common for your cron to not run for an entire day?
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?
-
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. -
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?
-
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.
High Availability
in Support
Posted
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.