Tyson

If you go to edit the payment account, next to the card number is a link to show the card once you enter your admin password. Can you successfully view the card number once you do that? This will tell us whether or not you have an issue decrypting the card number.

What's missing from the video is the gateway log for the attempted payment. What does it show? I'm still unable to duplicate the error on our test account, but it does seem strange.

Not sure I understand. The text and html tabs are 2 separate fields. If you type in one, then switch to the other, the text you just typed will not be displayed because it's under the other tab. Are you saying that when you type in one of the fields, switch tabs, then switch back, the text is gone? This shouldn't happen anywhere, and I don't experience it.

No, you would need to update the Universal Module to show the fields, but this will affect all universal module products, which may or may not be what you want. And as I mentioned previously, I'm not sure how best such a feature would be implemented here. As for currently getting the values of the fields, you can have them emailed to the client (and BCC'd to admins) be setting them in the package welcome email. The same tags are available as they are set in the Universal module, e.g. {service.hostname}

Yes, the format is along the lines of: {"name_of_service_from_the_name_column":{ "anything_that_makes_sense_for_describing_what_this_rule_does_and_must_be_unique_from_others_of_the_same_service_name":{ "rule":"isEmpty", "negate":true, "message":"The language to display when an error occurs due to this rule." } }} More described in the error checking docs. The universal module does not display the fields you enter when you manage a service, beyond what you've already discovered. There is no way to tell whether the fields you have set should or should not be shown on the service, since you may be collecting information for use in the system backend; you may not want to show the client; showing the information may need to be in a specific format that the module is not aware of; or the information may be useless to the client, but might confuse them if it were shown. It may be a nice feature to have, although I'm not yet sure how it would best work.

Based on the log in your screenshot, you don't have a credit card number set on your payment account, so when it sends credit card data to Stripe, there is no card to send, thus the card error. I suspect this is because you had the Stripe gateway set to 'store credit card data offsite', then you created a payment account (and it stored it offsite; i.e. card number is not stored in Blesta). Then you removed the 'store credit card data offsite' option from Stripe, and tried to provision a payment. Well, the payment account does not have any card data, since it's stored offsite, but it tries to send the card data from the payment account, which doesn't exist. This would be user error, since it doesn't make sense to require credit cards to be stored offsite, and do so, then try to use them as if they were stored in Blesta.

Setting that rule is redundant if Required is 'Yes'. Based on your screenshot, I don't see a "service_field_6" option set. You have "hostname", "ns1", "ns2", etc., but no "service_field_6", so I suspect your rule is triggering as an error because your service does not even contain the field, and thus is never submitted.

Coupons are applied to services, including their quantity, but your way would apply a total amount to an entire order irrespective of services' quantities. The latter would need to be a new feature.

If this is an issue with Payment Accounts, I'd expect to hear from more people about it. I'm more suspect of Stripe and how that's configured than anything else at this point. What version of Stripe's API are you using? You can find that in your Stripe account under API keys.

Did you uninstall the module after creating the package, thus removing the package's reference to it? It sounds like that may have happened. We plan to disallow modules from being uninstalled when they are assigned to packages, so things like this won't happen.

You should not do this as it opens up the entire application to XSS vulnerabilities. We don't have this issue. Can you show us what you're doing when you make the call to Widget::setWidgetButton()?

We're not able to duplicate this issue. It works fine for us whether stored offsite or not. Have you tried to create and use alternate payment accounts successfully when not storing card numbers with Stripe?

We need more information as described in How to Report a Bug. You briefly described the process of attempting a payment, but didn't include any gateway log information, or the information you have set in the payment account. Is this a live credit card number you're testing? If not, what is it? How can I duplicate your issue precisely?

Inclusive coupons are only applied if ALL of the assigned packages are ordered. If you're only ordering that one service, then you would setup a coupon that applies specifically to it alone.

I'm not noticing this issue. Can you provide steps to duplicate, including which module you were using?

This feature is in v3.1 of Blesta.

You can setup routes in /config/routes.php. There's not much documentation to illustrate this, but the syntax is similar to htaccess rules. Observe the warning when changing configuration settings: BE CAREFUL! Modifying these settings could have disastrous effects. Only modify these settings if you know what you are doing.

There's not a lot of information available regarding that error. You may want to ask ResellerClub support for more info. I would suggest double-checking your account credentials in Blesta, nameservers, that your account has that domain name, etc.

This would be why the email does not get sent. Some tag filter is incorrect. If you still have this issue, you can paste your email template content here and we can see where the issue lies.

The tag should be {service.solusvm_password} in the Welcome email template. The module re-uses an existing SolusVM account for each client, so the first time you create a service for a client, the password will be available, but for additional services, it is not. For example, if you add another SolusVM service to a client that already has one, then the existing SolusVM account is used, and the module does not know the password that was created for a previous service, and even if it did, it may have changed. Usually for cases like this, we setup the email template to say something similar to: {% if service.solusvm_password %} Password: {service.solusvm_password} {% else %} Your password is the same as your previous SolusVM service. {% endif %}

That is what was fixed in [CORE-868] - Coupon discount not affected by service quantity A 100% discount is just that -- 100% off the order. It does not recognize quantity as a limitation to the discount. Perhaps that would be a nice feature to have as a setting, though. Exclusive coupons currently take 100% off the order, while inclusive coupons do not. You could setup a 100% inclusive coupon, which I think would accomplish what you're expecting.

I've added CORE-895 to look into the 'address1' error. I think that field is actually required, in which case the documentation will be updated. The country/state issue sounds like another documentation error as well. Stating a field is 'optional' means it can or cannot be given; not that it can be given, but as an empty string. So in some instances, I can see unsetting a variable may be necessary. Likewise for the country field, it can or cannot be given when calling the method. The country field is actually required by the system, but optional when you call the method, only because it defaults to a value. But as you said, it seems silly to require a country but not an address, but I think the address is actually required. We'll take a look next week.

Closing as duplicate of another thread.

You need to setup an order form for any to be available, else you return back to the portal.

CubicWebs' solution has a number of syntax errors, which is why the page failed to load. IIRC, using the email address as the username is the default behavior, so I would think you could simply remove the <li> and the radio buttons altogether, but I haven't tested this.