serge

can not remember exactly but I think I done some "cleaning" like you did in my custom theme

wanah, on 31 Mar 2015 - 10:50 AM, said: For the number padding, I haven't found an official docment that states that it's obligatory, in 2007 our accountant told us we had to choose the right number of digits corresponding to roughly our sales estimates + 1 or 2 zeros. I'm in France and never heard about such requirement for Invoice number structure, the law never go deep in such detail where it's to each business to setup his own rules, of course invoice number must be chronological and without missing number, and that's it.
 
But some accountant people like to setup their own religion...

using port 465 for SMTP was revoked technically By the end of 1998!
 
http://en.wikipedia.org/wiki/SMTPS
 
So yes since it was revoked 17 years ago, it's VERY OLD FASHIONED ;-)

same line as you ;-)

If customers can upgrade those packages now, then they will still be upgradable with the proposed change. The proposed change only adds a filtering option that allows you to disable package upgrades within a specific package group. This does not span over multiple package groups.
 
Support for trial package upgrades to a paid package is a separate feature described in CORE-504.

I can see how that would be an issue for domains.
 
We think the solution would be a new option that allows you to determine what package groups allow upgrades/downgrades. So when adding/updating a Package Group, there would be an option to "Allow package upgrades/downgrades within this group". If unchecked, no packages within the group can be upgraded/downgraded.
 
All of the current settings will still be in effect, e.g., only packages from the same module can be upgraded, and clients can only upgrade packages if you have the setting enabled for them to do so.
 
Do you think that would be a viable solution?

what you said is interresting, I personaly do not work yet with domains even if the setup is ever in place and like you said one extension by package for having flexibility to change price by extensions.
 
For my need I removed possibility to upgrade package, I sell software licence and my customer can not upgrade from trial to paid, they just order appropriate licence, as I was not 100% certain Blesta manage well such upgrade, I do not want issue for later
 
And yes upgrade package (domain) should not allow makes confusion to customer, you are correct.
 
 
I think the upgrade package option (enable/ disable) should be allowed at package level and not only for the entire Blesta system (all packages) like it is by now

same line as you ;-)

Great finding. This is a BIG problem, I have tested and can confirm this issue (latest Blesta 3.4.3), this cannot, ever, never, happen on Domains On Domains people only have to have the option to Change "Terms" and not "Change Package"
 
I consider this as a BUG, because its not the intended way for Domains to Work.
 
I Will open a BUG post for this to be resolved

Thanks for bringing this up, and for including the term that led to the error. We'll look into the problem shortly.

ok, good idea, disable/enable some display/feature using code hack in client template :-)
 
 
I suppose this kind of option should be allowed from blesta admin interface as it's more something being native-needed in essence than custom

Shouldn't there be a novalidate-cert option with whatever IMAP function Blesta is using? I don't see the point of having another company signing my certificate over me signing it.

Awesome, thanks for the update!

what you said is interresting, I personaly do not work yet with domains even if the setup is ever in place and like you said one extension by package for having flexibility to change price by extensions.
 
For my need I removed possibility to upgrade package, I sell software licence and my customer can not upgrade from trial to paid, they just order appropriate licence, as I was not 100% certain Blesta manage well such upgrade, I do not want issue for later
 
And yes upgrade package (domain) should not allow makes confusion to customer, you are correct.
 
 
I think the upgrade package option (enable/ disable) should be allowed at package level and not only for the entire Blesta system (all packages) like it is by now

what you said is interresting, I personaly do not work yet with domains even if the setup is ever in place and like you said one extension by package for having flexibility to change price by extensions.
 
For my need I removed possibility to upgrade package, I sell software licence and my customer can not upgrade from trial to paid, they just order appropriate licence, as I was not 100% certain Blesta manage well such upgrade, I do not want issue for later
 
And yes upgrade package (domain) should not allow makes confusion to customer, you are correct.
 
 
I think the upgrade package option (enable/ disable) should be allowed at package level and not only for the entire Blesta system (all packages) like it is by now

regarding sending of email & this error I had in blesta email log at using my mail-server: "Unable to connect with TLS encryption".
 
I had feeling my ssl certificate (being self signed) was no more accepted since my php version update, as before that all was fine.
 
So I bought a ssl certificate, and installed it (my mail-server is on an other server than blesta).
 
And now it's just work fine!!!

regarding sending of email & this error I had in blesta email log at using my mail-server: "Unable to connect with TLS encryption".
 
I had feeling my ssl certificate (being self signed) was no more accepted since my php version update, as before that all was fine.
 
So I bought a ssl certificate, and installed it (my mail-server is on an other server than blesta).
 
And now it's just work fine!!!

there was maybe a learning step at mandril , delivery now is made on 5mins vs 30 mins before, so I will stay with mandril,

Sure that's possible, but why should I have to do that every time a spam-bot decides to email our helpdesk and it has an auto-replier on it?  That's obnoxious for folks of any size.  Perhaps for you it works, but that's not feasible for me.

CORE-1605 - When proforma is converted to an invoice, set date billed to current date
 
Also, CORE-1561 - Requeue invoice for delivery when converted from proforma
 
Both of these should be in 3.4.3 as soon as next week.
 
That leaves 2 things I believe, please correct me if I'm missing anything.
 
1. CORE-1287 - Prevent Proforma and draft invoices from reusing numbers. This is more complex.
2. Do not display date due on invoices converted from proforma.
 
On #2 I think some more discussion is required. There are a couple ways to do this:
 
1. Have an invoice settings option to disable the display of due dates on all invoices. This may be useful for those who do not use proforma as well.
2. Do not display due dates on invoices that were created from paid proforma invoices. If we do this, we need to store more information on the invoice that indicates that it was previously a proforma invoice, possibly another field in the table.
 
Thoughts on #2? Thoughts on CORE-1605, CORE-1561, or CORE-1287?
 
EDIT: Also, to add, it would be simple to remove display of the due date on invoices that are not proforma with a little code. So, while we come up with the best solution, you could make this change now to affect all invoices (but not pro forma).

agree on this:  I like the idea. But -1 for saving images in database . I prefer save them in upload directory outside the public_html .

So i can resume , the due date should be showed in proforma invoice , after convertion to final invoice is not needed to be shown , for that reason is safe to not change the due date . It remain a reference for proforma invoice .

Lol, my mistake sorry Cody and naja7host
Naja7host is right its not a problem in due date because we do not legally need that field on final invoice, only need on Pro-forma for customers to see

I like the idea. But -1 for saving images in database . I prefer save them in upload directory outside the public_html .
Or add ability to attach notes with transactions.

It doesn't look like mysqli is removed in php7 so you shouldn't have any issues.
I personally prefer PDO just because I can almost seamlessly support multiple database types without changing any code.