Tyson

The example was mainly to determine what the expectation is for where tax amounts appear in the totals listed. I believe I understand the differences you're striving for, but to reiterate, could you provide the amount values for the following example? EXAMPLE PRODUCT: Price: 100.00 (taxable) Setup Fee: 5.00 (not taxable) Tax rate: 10% Inclusive Subtotal: ? Tax: ? Total: ? Invoice Total (what the client is charged): ? Exclusive Subtotal: ? Tax: ? Total: ? Invoice Total (what the client is charged): ?

So if the package price is £2.40, is the following correct? Inclusive Subtotal: £3.00 Total: £3.00 Including VAT @20%: £0.60 Exclusive Subtotal: £2.40 VAT @20%: £0.60 Total: £3.00 Either way, the customer pays £3.00. You just show the tax inclusive in the total or exclusive not in the total?

So in other words, the Feed Reader should support not subscribing to any feeds? The idea of it is that when no feeds are subscribed to, staff are automatically subscribed to the default feeds for the plugin. This is useful, for instance, when adding a new staff member--they don't have to configure the feed reader since they'll start with the default feeds.

You can just manage the Feed Reader plugin under Settings > Plugins > "Manage" (Feed Reader) and delete the feeds there.

You can set a Text-type Service Option on your Universal Module product to make it available to be set when a customer orders the product. However, the invoice reminders don't currently include information on any service(s) apart of the invoice.

The equivalent of the change you mentioned would be to update /core/ServiceProviders/MinphpBridge.php and change: $htaccess = file_exists($rootWebDir . '.htaccess'); to $htaccess = true; That said, I have not tested this with Nginx and am not sure whether this will work for you.

The widget on the admin dashboard will unsubscribe you from the feed. It will delete the feed if the feed only exists for your user account and it does not exist under Settings > Plugins > Manage (feed reader). If the feed exists on the plugin itself under Settings > Plugins > Manage (feed reader), it is a "default feed". This means if the user is not subscribed to any feeds, they will be subscribed to the default feeds. For example, if you go to the admin dashboard and remove all feeds, you will automatically be resubscribed to the default feeds defined under Settings > Plugins > Manage (feed reader) even if you had just removed it. This can give the illusion that removing a feed did not work--it did, but the default feeds were resubscribed to them automatically. Is this the behavior you're experiencing?

Sorry, the translation is a little confusing. Are you asking how to delete a client that has services and transactions on their account? If so, that is currently not possible until Blesta version 4.3.0 is released (soon).

When you save the credentials, the system tries to test the API by checking that the 'namecheap.com' domain exists by POSTing an API request to Namecheap with your credentials. However, Namecheap did not return an 'OK' response, or the system could not interpret the response. The module requires the libxml php extension to be enabled on the server, so you may want to double-check that it is.

The yellow notice appears if the following conditions are met: The contact has permission to view invoices (it appears this is true) There are open invoices in at least one of the currencies (it appears this is true) There is a message to display from the language file regarding the amount due (this is probably true, but I am unable to determine that from the screenshot) Check that there is a message defined in your language file, /language/LANGCODE/client_main.php, for "ClientMain.!info.invoice_due_text" and "ClientMain.!info.invoice_due_past_due_text"

So PayPal is not notifying Blesta that a payment was made? That sounds like it may be an issue with PayPal, no? Have you tried to ask their customer support why recurring payments are not making IPN calls?

The restricted packages are currently only orderable by admins from the admin interface. However, v4.3 addresses both of your concerns via CORE-718. That is, clients will be able to order restricted packages through the order plugin, and the order plugin will only display the package group if it contains at least one restricted package the client can order.

Have you taken a look at the Shared Login plugin for Blesta? I would have used that plugin to allow for SSO to Blesta, or integrate OAuth support with something like this Wordpress plugin. This will get you to log in to Wordpress via Blesta. From there, you can use Blesta's API to retrieve information on the client, like whether they have any services, and redefine their role in Wordpress. If Blesta needs to push notifications to Wordpress, you can create a Blesta plugin that listens to certain events and makes API requests to the Wordpress installation to perform necessary actions. Regarding user authentication passwords, these will never be decryptable in Blesta and they're not supposed to be encrypted anyway for security reasons.

A configurable white/black-list would probably be nice to have for filtering what clients can see and use certain gateways. We've had requests not only for filtering by country/state/province, but also for specific clients themselves, or for specific packages. This filtering can be a little difficult to manage though, since you may create order forms that many clients are unable to use to make payments because all the gateways have been disabled. We'd have to display that better in some location. Based on your example, the expectation when calling GatewayManager::getAll is to retrieve all gateways, so it's unlikely we would update this to allow filtering by event. Having a separate method, like GatewayManager::search($options), would be better.

So you would like to be able to define which client fields from the "Required Client fields" page can be edited by the client?

What would you expect to see for indicating whether a line item is a new service or a renewing one? [New] Package Name - Service Name (Apr 12, 2018 - Apr 12, 2019) [Renewal] Package Name - Service Name (Apr 12, 2018 - Apr 12, 2019) [New] Package Name - Service Name [Renewal] Package Name - Service Name

Package Name - Service Name (Apr 12, 2018 - Apr 12, 2019) This language is shown for any service (newly created, or renewing) that is of a term that is renewable (e.g. 1 month). Package Name - Service Label This language is shown for any one-time service that does not renew. All of the service line items start with that description, but are overwritten with the renewal one if they span over a date range.

Could you elaborate on the issue? It's difficult to assess what value you're referring to is incorrect. The tax type (inclusive/exclusive) will only control whether the tax amount is displayed as apart of the total or not. For example, I tested an order for a $1.00 package that is taxed exclusively at 10% for client #1 and taxed inclusively at 10% for client #2. The tax rates in the examples below are configured as: Clients in the US are charged 10% with a tax type of 'Exclusive'. Client #1 is in the US Clients in the UK are charged 10% with a tax type of 'Inclusive'. Client #2 is in the UK Client #1 (with exclusive tax) sees on the order checkout page: Product Price $1.00 Subtotal $1.00 Tax (10%) $0.10 Total $1.00 After placing the order, an invoice is created and the client is charged $1.10. On the order complete page, the client sees: Product Price $1.00 Subtotal $1.00 Tax (10%) $0.10 PAID $1.10 ---- Client #2 (with inclusive tax) sees on the order checkout page: Product Price $1.00 Subtotal $1.00 Tax (10%) $0.10 Total $1.10 After placing the order, an invoice is created and the client is charged $1.10. On the order complete page, the client sees: Product Price $1.00 Subtotal $1.00 Tax (10%) $0.10 PAID $1.10 How do these examples I described differ for you? What value is incorrect and what do you expect it to be?

Was the service created in Blesta? It seems as though it was not, perhaps due to an error with the module.

The AdminManagePlugin controller is a special controller (see docs for reference) that loads the plugin management controller from /admin/settings/company/plugins/manage/PLUGIN_ID/ in Blesta. If you want your mapping to be managed similarly, you should create methods in AdminManagePlugin to do so, and use GET arguments to request your specific AdminManagePlugin method (e.g. "AdminManagePlugin::refresh" is called when visiting admin/settings/company/plugins/manage/PLUGIN_ID/?action=refresh). If you want to manage your plugin elsewhere, such as from its own page, you can certainly do so however you'd like, as the plugin's controllers can be requested directly at their own URI, e.g. /admin/plugin/feed_reader/my_controller/my_method/

Yes, you'll need to provide the unsent delivery methods if you would like them to be maintained. The use of models will be updated in the future to provide better and more succinct actions for updates like these.

It's always assumed that attackers have any username/email/etc. about you. Security through obscurity is not an acceptable deterrent.

Modules handle domain registration, and there are no endpoints directly to the module for any action. In that case, it may be better to have a plugin installed on the system with which you can call via the API instead, and then that plugin can load up the appropriate module/service/etc. and perform those actions--assuming, of course, that the module you're working with supports registering a domain, updating nameservers, and renewing it. You can use the Users endpoint to verify credentials.

We've decided to update this in CORE-2630 for v4.3.0 to have the event trigger after we've set the language, so in your case, you'll be able to override it.

A white screen is indicative of a 500 internal server error or a php fatal error with error reporting disabled/suppressed. I would suggest enabling error reporting or checking your php error logs for the error that was encountered during runtime.