will

How does one place an order just by interacting with the API rather than the order form? I'd like to replicate all the actions that would occur when using the order form. New users can be created with the User model, but what needs to be done to ensure that a new service is created and invoiced? A new service could be created via Services->Add. This can even notify the user that the service has been created. Will it create the initial invoice as well, and activate the service once that invoice has been paid, or does the order plugin need to be used for all of that to happen? The order plugin has models available that aren't documented at http://source-docs.blesta.com/package-blesta.app.models.html (presumably because they are plugin models rather than base Blesta models) It looks like the "add" function in plugins/order/models/order_orders.php may be what I'm looking for - is that all I need to call, or is there some additional work that needs to be done to complete this process?

I'd like to add a tab to the logs page under the Tools section for a plugin I'm building. Is this possible? What's the best way to go about this? Are there any plugins that implement this that I could look at? I noticed the PHPIDS plugin implements a logging system, but it keeps its logs under its own management page rather than adding them to Tools>Logs.

Is Blesta backwards compatible with modules from 3.6.2? Does anything need to be changed for a 3.6.2 module to work with Blesta 4?

Is there a changelog for the updates made between Universal Module 1.3.1 and 1.4, the version offered in the Blesta 4.0.0. beta 1?

It looks like CORE-710 is marked as private - I get a login screen when I try to take a look at it. ( http://dev.blesta.com/browse/CORE-710 ) Can it be changed to public?

If this is not a current feature of Blesta, then yes please.

Is it possible to include all outstanding invoices whenever Blesta emails a customer about an open invoice? We've had a few cases where a transaction was not recognized by Blesta, so a customer thought they paid the invoice but Blesta did not, and that invoice languished while the customer kept up to date with subsequent invoices. Alternatively, a line indicating the total amount due for an account (rather than, or in addition to, the amount due for the invoice) would probably suffice to get a customer to log in to the billing panel where they would notice all outstanding invoices.

Don't forget to configure your SSL for stronger security! See https://mozilla.github.io/server-side-tls/ssl-config-generator/ to help you decide on what level of security you want to employ. The trade-off that comes with the strongest of security is dropping support for older browsers. For most of Blesta's markets, I suspect you won't be breaking things for very many customers if you go with "modern" security, and chances of breaking things for *any* customers are slim if you go with "intermediate" security. "Old" security includes support for SSLv3 which is known to be broken. Do not use the "old" option unless you absolutely have to. (Warning: if you haven't configued OCSP stapling or HSTS before, I strongly recommend you test them on a non-production server first, as screwing the config up make your site inaccessible... potentially for the duration of max-age. Use a very small max-age while testing.) The config generator mentions a "dhparam.pem." You can generate a DH parameter file with openssl dhparam -out dhparam.pem 2048 You want at least 2048 bits in light of the Logjam attack. We force SSL for all connections to Blesta. (Also, if you want to support ipv6, you'll need to specify that you want to listen on ipv6 interfaces.) server { listen 80; listen [::]:80 ipv6only=on; # This last flag can fix some issues nginx can have with binding to ports. server_name mydomain.com; return 301 https://$server_name$request_uri; #Force SSL } server { listen 443; #SSL Only listen [::]:443 ipv6only=on; #For ipv6 server_name mydomain.com; # The rest of the config goes down here } EDIT: If you want to be paranoid (e.g. security bonus points) your config directory should be readable by PHP, but not nginx. Similarly, your SSL certs should be readable by nginx, but not PHP. On top of that, your DB should be protected by your firewall - there's no reason for it to be listening to any requests except local ones. One more thing: you can tell nginx to ignore requests for sensitive files or folders. location ~ ^/(cache|config|errors|helpers|internal|language|lib|index.php/api|api) { deny all; return 404; } # If you're using your API with some kind of external service, you can remove those last two. # If that service has a static IP, you can add "allow x.x.x.x;" on the previous line, where x.x.x.x is the service's IP.

+1 It would be great to have access to a git repository for the purpose of pulling in updates, and being able to send pull requests upstream would also be pretty nifty. As a suggestion to the OP, the way we do it is we maintain two branches - master, which tracks the official codebase, and a branch with our production changes. When there's an update, we drop the update on to the master branch and then merge that in to our production branch. If these are Git repositories, Git actually makes this fairly easy with the submodule feature. (Even if you don't publish a repo, this feature may be useful to you internally.) PS I don't have any experience with JIRA outside of tracking issues as a Blesta customer, so there may be benefits I'm not aware of, but if the only real stumbling block for using JIRA rather than GitHub issues as you migrate to Git from SVN is the concern of loss of tickets & corresponding history, this tool might be worth looking at to ease migration. https://github.com/brianhayes/jira-to-github-issues

Yeah, it looks like Swiftmailer supports S/MIME, but I think that's of less interest to our customers. It does look like I can add parts to the body through Swiftmailer, though, so I'll probably modify the send function in /components/email/email.php to change the message's type to "multipart/signed", compute a signature for the "text/plain" portion, and add a part named "application/pgp-signature" with that signature contained. If anyone's interested in the code, I can share it when I'm done. (It's pretty low on my priority list right now, though, and it will unfortunately be hardcoded, not exposed through the admin console.)

Several of our customers have inquired whether or not we could sign our communications from Blesta with GPG. (Doing so with PGP would probably be even better.) How hard would this be to implement? What part of the codebase would need to be modified?

That's weird. Those pages do seem at odds with their API page; it looks like it's supported by their API. From https://bitpay.com/api /invoices/:invoiceId/refunds Creates a refund request for the given invoice. Response Name Type idRefund request resource idstring requestDateTime of API calldate statusCan be `pending`, `success`, or `failure`string tokenAPI token for invoice refund request resource EDIT: It looks like it's a relatively recent addition to their API. http://blog.bitpay.com/2014/09/18/announcing-the-new-bitpay-api.html

Are there any plans to add support for refunds to the Bitpay gateway?

I imagine their motivation is the increased speed, security, and privacy that comes with disabling JS. I'm not interested in debating whether or not this is a reasonable choice to make; I don't think our company has any business criticizing the browsing habits and security procedures of our users. If they don't want to use JS, as far as I'm concerned that's their prerogative. Ok. We've had fewer than a dozen complaints, so we're planning on simply offering to handle any interactions they need to take care of through our support email system rather than through the website.

We put Blesta in to production recently and a few of our customers have complained that the site doesn't work for them without JS enabled. Is it possible to get it working without JS, or is that integral to functionality? I'm talking strictly about client-facing areas; having JS on the admin side is not something we're trying to work around.