[Removing Certain Elements From Client Area]

of coure you can hide it by this css :

.row .col-md-3 .list-group :first-child {diplay:none;}

and select client area in simple page .

 

To make this work, I had to change :first-child to a:first-child

[Support Module Doesn't Receive Email]

Resolved!

I will explain how I fixed these email issues, but first I want to acknowledge that it was ultimately about my server’s configuration, not a problem with Blesta.

I also thought I should give a lot of detail here, in case it helps anyone else experiencing these issues.

For reference, I’m on a shared hosting reseller account using cPanel. Other systems are likely a bit different. Additionally, Blesta is installed in the webroot of the dev subdomain.

Part 1 - Mail piping

I think this is more of an issue for people who don’t fully control their server, such as shared hosting resellers, because our options for changing server defaults are limited.

As Blesta’s manual states, “The Support Manager requires the MailParse PHP extension in order to parse tickets sent in through email.” Since Mailparse was not available on my server by default, I asked my provider to install Mailparse in my cPanel account and add a custom php.ini file in my dev directory, the path to which I then defined in the Blesta .htaccess file with SuPHP_ConfigPath.

SuPHP_ConfigPath /home/username/public_html/dev/

This works fine for anything accessed in a browser, so when I set up a support department to use email, Blesta didn’t give me any errors.
 
However, it doesn’t necessarily work for commands run via the command-line interface (aka CLI), such as the cron automation used for POP/IMAP retrieval, or the pipe.php script used for email piping. This all depends on your server’s PHP configuration. I had seen references to this in other posts, but I don’t recall seeing specific examples of potential solutions. Since I’d never had to deal with this particular issue in my other web applications, I dismissed it as being irrelevant to my situation. Wrong!
 
My provider’s support team finally realized that my custom php.ini, and therefore Mailparse, wasn’t being used by the cron or pipe.php.

For the cron job, I was able to rectify this by using php -c path to include the custom php.ini.

New cron:

/usr/local/bin/php -c /home/username/public_html/dev/myphp.ini -q /home/username/public_html/dev/index.php cron

For pipe.php, it was a bit more challenging, because I continued to get a bounce error after I appended -c /home/username/public_html/dev/myphp.ini to the hashbang that cPanel had added to the beginning of the script when I set up the mail forwarder to pipe.
 
Eventually, I found this post, which explained that PHP apparently only allows one argument in the hashbang. I finally got it to work by concatenating -q -c and path into one argument.
 
New pipe.php hashbang:

#!/usr/local/bin/php -qc/home/username/public_html/dev/myphp.ini

Success with email piping!
 
I had a working system, so I could have stopped there. But, I also wanted to figure out why POP/IMAP still wasn’t working, even though I didn’t really need it because I now had piping.
 
Part 2 - POP/IMAP Retrieval

The above cron tweak should have fixed my POP/IMAP retrieval issue, so I was surprised when Blesta still didn’t retrieve email.

Again, my provider’s support team found the problem. This time, it was a mail hostname issue that appears to be due to a bug in cPanel.

When I created the dev subdomain, cPanel’s mail client configuration page said to use mail.dev.mydomain.com for the incoming server. However, cPanel failed to create the corresponding DNS record, so checking mail using that hostname failed. I didn’t catch this earlier, because I was using a webmail client that accepted my username and password, but didn’t require the server/host name.

All I had to do was switch Blesta's support department to use my main domain’s mail hostname (mail.mydomain.com) or the server’s generic one.

Problem solved!

All Blesta mail is now flowing as it should, whether incoming or outgoing, piped or retrieved via POP/IMAP. 

[Forcibly Generate Service's Next Invoice]

+1

 

I'd like to add that I think clients should be able to renew any recurring service at any time on demand from their portal. Upon payment, the system would then send them an invoice marked paid, and the service term would be extended by the selected amount from their current renewal date.

 

For those that need a bit more control over renewals, perhaps provide a new setting in the package to allow/disallow customers from renewing until they receive the renewal invoice. In other words, the ability to toggle each package between the current Blesta behavior and this new proposal.

[Support Module Doesn't Receive Email]

upload the support manager plugin from clean blesta source , and try again .

 

also make sure you have set the correct path in blesta settings .

 

I deleted support manager, then downloaded a fresh copy of 3.3 from the Blesta website and uploaded a new copy of support manager directly from it to my installation. I also deleted my mail forwarder and re-added it. cPanel automatically set permissions and added the correct hashbang to pipe.php

 

I double checked that the path in Blesta settings was correct.

 

Still, I get the same mail bounce error when trying to pipe, and no mail is retrieved when trying to use POP or IMAP.

 

You might not have a mail parser on the server.

 

I do have mailparse, as per my first post. phpinfo confirms that mailparse is installed. But I will ask server support to double check mailparse, just in case there is an issue with it.

 

I appreciate all your efforts to help me try to resolve this! I hope we find a solution.

[[Universal Module] Service Details]

This might be something we can do by setting a checkbox next to each service field that you add.

 

+1

[Support Module Doesn't Receive Email]

My my server support team sent me the following message:

 

We believe there is a problem with your PHP script. While running strace on the pipe process my colleagues found that it hangs while trying to read one of your PHP includes:

 

lstat("/home/myusername/./attachment.class.php", 0x7fff42ae46e0) = -1 ENOENT (No such file or directory)

 

The file /home/myusername/./attachment.class.php clearly does not exist so you'll need to adjust your file paths manually to ensure that it looks for attachment.class.php in the correct location. If you continue to experience difficulties with your pipe script, please also ensure that you use binary mode while uploading through an FTP client. The correct path for attachment.class.php appears to be the following:

 

/home/myusername/public_html/dev/plugins/support_manager/vendors/mime_mail_parser/attachment.class.php

 

Does this mean that pipe.php is somehow including an incorrect path?

 

I'm using Blesta 3.3 and pipe.php is unchanged, except for the required hashbang we've added at the top.

[Removing Certain Elements From Client Area]

In addition to hiding the "Change this" text, it should disable the link to attempt the change. It's kind of strange right now that a client can click the link, only to be taken to a page where he can't actually change anything.

[Removing Certain Elements From Client Area]

I don't mind having that invoice box tell the client what method is being used. However, I think Blesta should be smart enough to automatically hide the text about changing the invoice method, if there is only one choice or if we've disabled the client's ability to change the method.

[Support Module Doesn't Receive Email]

Weird it might be the like the issue a client had, but he's crons didn't work on cPanel either which is why he moved to another control panel. Are you hosting on your own VPS or a reseller account?

 

I'm not on a VPS, just a reseller account.

 

My cron runs fine. All other Blesta tasks appear to be happening as scheduled. I also have a handful of other cron jobs that run for another app on this account without issues. As far as I can tell, it's not a problem with cron.

 

Piping also works in the other app on this account, so I'm thinking that it's got to be something specific to Blesta.

[Support Module Doesn't Receive Email]

Try using /usr/bin/php depending on your cPanel installation that might be the correct one.

 

/usr/local/bin/php is definitely the correct path for my installation. It's the only way anything else works.

[Support Module Doesn't Receive Email]

I have been unsuccessful in my attempts to get the support module to receive email.

 

When I try piping, I get a bounce with the following error:

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

pipe to |/home/myusername/public_html/dev/index.php plugin/support_manager/ticket_pipe/index/1
  generated by support@dev.mydomain.com
  local delivery failed

When I try IMAP or POP retrieval, nothing is retrieved or marked as read/deleted.

 

The various Blesta logs show nothing. No errors are logged on my server.

 

Sending email from Blesta, including support responses for tickets submitted online, works fine.

 

I’ve read every thread in these forums that I can find for email or piping, but nothing has proved a solution for me.

 

cPanel WHM 11.42.1 (build 26)

PHP 5.3.28

MySQL 5.1.67

CENTOS 5.11

 

I’ve made sure that my support address is correctly forwarded for piping in cPanel.

 

I’ve tried piping using both pipe.php and index.php, with and without the hashbang.

 

I’ve made sure that my php path (/usr/local/bin/php) is correct in the hashbang and cron. All other Blesta cron tasks are working fine.

 

I’ve confirmed via phpinfo() that Mailparse is installed (and I didn’t get a mailparse error when I selected piping in the support department). FYI, in my situation I have to use SuPHP in the Blesta .htaccess file to include mailparse.

 

I’ve tested that the given IMAP and POP credentials work in my mail client.

 

I’ve tried manually running the cron.

 

I’ve made sure that all related directory and file permissions are 755 or 777.

 

I have another application installed on the same cPanel account as Blesta, and piping to it works perfectly. I’ve double checked that all permissions, php paths, piping settings, etc. are the same in both apps.

 

This is driving me insane! I don’t know what to try next.

[[Module] Opensrs - Beta 1.0.8 Relesed :)]

what you have in log module ?

 

I didn't even think to check the log. The answer was right there. Log module output said "[...] Request failed validation: Name server 'ns1.mydomain.com' is not found at the registry. Please double check the nameserver and re-submit. [...]"

 

I forgot that the OpenSRS test environment usually doesn't recognize our nameservers and recommends that we use theirs:

 

default.opensrs.org

default2.opensrs.org

 

As soon as I changed this in my Blesta package, I was able to add the service and the test domain was successfully "registered"!

 

Thanks!

 

Looking forward to more of the features becoming available!  

[[Module] Opensrs - Beta 1.0.8 Relesed :)]

Do I still have to patch the two files if I don't use separate pricing for register/transfer/renew?

 

I didn't do the patch and am getting an error "Invalid Domain" when I try to add the service in the admin panel. The service is not added to Blesta, but the domain appears in my OpenSRS test account (sandbox).

[[Module] Opensrs - Beta 1.0.8 Relesed :)]

I'm going to try it later today!

[Logo Not Scaling]

Will do. Thanks for confirming.

[Cpanel Module (Enhanced Integration)]

I'm curious as to why you don't want to use the IP address for temporary access to both ftp and url? This has always worked great for me.

[Logo Not Scaling]

This vQmod will make the logo responsive as long as you haven't already modified that part of the structure.pdt. You can look at the generated file in vqmod/vqcache to find out what the resulting structure.pdt looks like when the changes have been applied.

 

I wasn't able to make this work without manually modifying the css file. This vQmod inserts the .img-responsive class in structure.pdt, but isn't overwriting the .logo class in styles.css.

 

According to About vQmod, "css & js files - These files are rendered at the browser level, not at the server level, so vQmod has no effect on these."

 

Is that the case here, or do I need to hunt down a gremlin? I guess it doesn't really matter, because I can just continue to use my manually modified css file. But I'm curious.

[How Do I Delete A Recorded Charge After I Add It?]

Sounds like a good idea for a plugin

 

Accounting integration or housekeeping? Or both? 

 

I'd love to see a plugin that would allow Blesta to integrate with, or export to, AccountEdge

*If* you could delete transactions, you probably wouldn't want all your staff to be able to do the same. Making money disappear in one area, sometimes mean it is re-appearing in someone's pocket, off the books. That's money laundering. If you can tell your auditor that Blesta doesn't allow you to delete transactions, then it makes you look a whole lot better and raises fewer questions. I'd rather explain why there's a voided test transaction than be under the heat lamp. In the grand scheme of things, it doesn't take up much space in your database, and space is cheap.

 

I appreciate your commitment to data integrity and I agree that it can be a selling point, especially for accountants.

 

I can live with the data remaining in the database, but I'd really like to be able to delete (i.e. remove from the interface) invoices and such, if I know they aren't important to my audit trail. Perhaps you could deal with them the same way you deal with deleted tax rules (and maybe other stuff), where you remove them from the interface but leave them in the database. That way, I can clean house and keep the data intact in case it's required for audit purposes.

[How Do I Delete A Recorded Charge After I Add It?]

The purpose of this is for accounting purposes in most instances.  Even if it's voided, you still don't want to delete it as it could raise questions down the road if you are ever audited/etc.  Having a valid record of every transaction should be preferable in every situation.

 

While I agree that every valid financial transaction should have an audit trail, it doesn't mean that every error or test entry should remain visible in the interface (or loiter in the database). Let's face it, we're working with quickly evolving software and every time there's a new or modified feature some of us will misunderstand how it works and make a mistake, or maybe just test it to see how it works. These things don't need to be indelibly recorded in our record books.

 

If there's one thing I've learned from reading these forums, every jurisdiction in the world has different accounting rules and record keeping requirements. Blesta can't be expected to police users for every possible scenario. Besides, Blesta isn't accounting software; it doesn't do all of the things necessary to keep your financial records in order. Blesta is online billing software with resource management.

 

Personally, I don't want to be restricted from doing some basic housekeeping simply because the rules/preferences are different for someone else. I want to have a choice about what information I delete (unless it breaks Blesta) and I'll live with the consequences.

[Domain Module]

What we are trying to do is on OpenSRS new Domain Module (and we will also implement on outhers), to in Admin Side, wen changing the Package and/or Term, be able to execute the Renew Command for the xx years selected, because we cannot manually renew domain in Blesta without an Renew Invoice.

 

I like this concept.

 

I wish Blesta would allow customers to renew domains and other recurring items at any time, rather than waiting for a renewal invoice. To me, it's especially important for domains. I'd like to be able to send 90/60/30 day domain expiry/renewal reminders (like the big guys do) and actually let the customer renew at that time. Currently, I have to suppress any OpenSRS reminder emails to customers, because the customer won't be able to renew until my billing system issues the invoice only a few days prior to expiry.

 

P.S- OpenSRS almost Done, and we are only doing minor optimisations like this one 

 

This is good news! OpenSRS/Tucows is the only registrar I resell, so this module is necessary before I can fully commit to Blesta.

[Changes In The Way Billing Works]

- making an invoice void or doing a refund/partial refund should generate a new invoice with negative line items,

  including proper negative vat 

 

I like the idea of an one-click option to create a new credit note (aka credit invoice) for the same amount as the original invoice, which essentially reverses the original invoice for accounting purposes. However, I don't believe this should be the default behavior for voiding/canceling an invoice, as I'm in a jurisdiction that will allow me to simply mark the invoice as void or canceled, unless the customer has already made a payment on it.

 

- payment type - invoice needs to have a payment type on it (Bank transfer, Paypal, etc)

This is okay, as long as it only shows the payment type(s) on paid invoices. I don't want unpaid invoices to show the default payment type, because customers may choose another type at time of payment.

[Invoice Rounding In Different Currency]

 

It's called Swedish rounding

 

According to the article, rounding with 0.05 intervals is currently in use in:

• Argentina (always rounded down)
• Australia
• Bosnia and Herzegovina
• Bra7i1
• Canada
• Finland
• Hungary
• Malaysia
• The Netherlands
• Singapore
• South Africa
• Switzerland
• Turkey

 

 

In Canada, this special rounding only applies to cash transactions, because Canada eliminated the penny (0.01) in 2013, leaving the nickel (0.05) as the lowest currency denomination in production. Additionally, the rounding only applies on the final total, not on line items or tax calculations.

 

According to the Royal Canadian Mint, "only cash transactions require rounding.  Cheques and transactions using electronic payments—debit, credit and payments cards—do not need to be rounded, because they can be settled electronically to the exact amount."

 

More info can be found here http://www.mint.ca/store/mint/about-the-mint/phasing-out-the-penny-6900002

[Blesta Have Option To Create Quote/estimates ?]

I like Cody's suggestion to allow draft invoices to be manually sent from the client profile. Perhaps they can be flagged in some way, such as a pop-up asking you to confirm that you want to send a draft invoice.

 

Personally, I don't need a whole quote system, as I only do this once every year or two. Sending a draft would work fine for me. Call it a quote, if you'd like, but the intent is the same, which is to mutually agree upon a final price. Once agreed, the draft is converted into a regular invoice for payment.

[Setting An Email Return-Path For Bounces]

Found it!
 
In components/email/email.php at line 90

private function newMessage() {
  $this->message = Swift_Message::newInstance();
  $this->message->setMaxLineLength($this->max_line_length);
  
  $this->message->setCharset($this->charset);
}

add this line before the closing curly bracket:

$this->message->setReturnPath('bounces@example.com');

so that you end up with this:

private function newMessage() {
  $this->message = Swift_Message::newInstance();
  $this->message->setMaxLineLength($this->max_line_length);
		
  $this->message->setCharset($this->charset);
  $this->message->setReturnPath('bounces@example.com');
}

It will add your custom return-path to outgoing mail.
 
It would be nice to see this as an option for each company in Settings.

[Selling Reseller?]

If you're a reseller of shared hosting, it's possible that your provider has disabled your ability to sell reseller accounts.