[RRowley]

Why include taxes in the unit price? What is the reason you can’t use the taxes feature of SI?

[RRowley]

Concern about the fax field. It is a field with a specific function. Believe it or not, fax capability still exists and is used. A better field would be to use a custom field. These are user defined, and if you use field 1 but another user already used field 1, then they could easily update their form to use field 2, etc.

[RRowley]

This is a beautiful template. It also worked first try after loading it. There are two ways I can think of to include it. One is to make it the new default template. The other is to modify the .gitignore file to allow specific template directories to be included in the package. I’m inclined to do the later. One, it doesn’t disrupt people using the default who are satisfied with it. Second and more important, it is a way to allow others who want to contribute professional templates to the package to have them included. So I plan on including it as a directory option that can be selected in place of the default. Thank you again for this contribution.

[RRowley]

Thank you for your contribution. I’ll review what you’ve provided and see how it might best be shared.

[RRowley]

I encourage you to use the master_2019.2 version to make sure you have the most current corrections as well as working with a version that more easily supported. That said, is there additional information about this error in the tmp/log/php.log file?

[RRowley]

Please be specific as to the items set and the values they were set to so I can replicate and test it.

[RRowley]

In the templates/default/cron/add.tpl file on line 114. Remove the “/” before the terminating “>” sign. So this:
<input type=”hidden” name=”domain_id” value={if isset($domain_id)}{$domain_id}{/if}/>
becomes this:
<input type=”hidden” name=”domain_id” value={if isset($domain_id)}{$domain_id}{/if}>

[RRowley]

There is some database setting the is not allowing an empty string to work as the same as the numeric 0 default value for a field. The si_customers table default_invoice field is int type and has a default value of 0. The update command was sending in an empty string (”) when this field was not set. This caused an error to be thrown. This default works on my database but not yours which is why I think it is some DB setting that differs on you set up vs mine.

I updated the customer update screen to send a 0 in for this field. This change has been uploaded to the SI version github. The new SI version is 2019.2.11. You can copy the templates/default/customers/details.tpl file from github and replace the one on your install. See if that helps. If so, you should pull the entire update and replace what you have so the the version and other info gets updated also.

While this might fix the customer update, you might encounter a similar issue on other screens. So determining the database setting that lets mine work and yours not, will be the best all around solution. I’ll keep checking to see if I can find this.

[RRowley]

When you say “master release for php 5.2,” are you talking about a fearless359 version of SI or the original version of SI? The fearless359 master version has a version number of 2018.2.8_1 in the config/config.php file. If you are using the fearless359 master version, you should use php 5.6 as a minimum level.

If you can update to php 7.2 or higher, then you should consider upgrading to master_2019 or master_2019.2

[RRowley]

#3 above shows the error comes from a call of line 113 in the Inc/Claz/Email.php file. This does not match the current version of this source currently checked into github. Please download and install the current version of Fearless359 SI and test again. There was a specific change to the email security logic that was in version 2019.2.7.

If you have a gmail account, you might try routing through it. Here are the settings I use for testing sans username and password.

email.host = smtp.gmail.com
email.smtp_auth = true
email.smtpport = 465
email.secure = SSL

If the problem persists, excluding the username and password, send me the settings you have in custom.config.php for the email configuration.

[RRowley]

The fields would need to be present on the table list screens to be search items. There isn’t room for this. The way to do it would be to make a report for that purpose. You can do this by creating an extension.

[RRowley]

Check the email value settings in the config/custom.config.php file. Also might check the tmp/log/php.log file to see if there is more detail on the error.

One thing I had to do was enclose the password in single quotes (double will probably work). I think this was because I have special characters in my password.

[RRowley]

The numbering logic is complex. It keys off of the Invoice Preference setting for the invoice which in the preferences table, the record for that value specifies the Invoice Numbering Group to be used. This then ties back to records in the si_index table keyed by the constant node value of “invoice” and the sub_node value that comes from the Invoice Number Group. If you are confused, I don’t blame you.

To help, I uploaded changes for 2019.2.8 version that adds information to several screens and I updated the “How To …” topic for the “change the invoice number starting point” topic accessed from the menu on the left.

You need to have things set up correctly to get numbering to work. If you want any type of invoice to use that same numbering sequence, in the Inv Prefs records (under the Settings tab) should have the Invoice numbering group set to Invoice. Then they all use the same record.

[RRowley]

Uploaded fix that adds the email secure value to the encryption parameter for Swift Mailer transport object. I verified that this logic works with three different SMTP servers. So hopefully the email issue is resolved.

[RRowley]

Oops. That should be $config->email->secure (not encryption).

[Author]

Posts