@Braath Waate.
Is this safe to implement in the core now?
Joe
It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
FrontAccounting forum → Posts by joe
@Braath Waate.
Is this safe to implement in the core now?
Joe
Hello Guys,
I am aware of the problems. However using the built-in mail function has normally been working ok during the years.
Using phpmailer requires an existing account for using it.
Suggestions are welcome.
Joe
@PaulShipley
This was a PHP 7.X error. Thanks for finding this and showing the resolution.
Committed to repo. The fixed file can be downloaded here.
Joe
Which PHP-version is used?
Joe
This has been fixed and committed to stable repo. The AUTO_INCREMENT removal will wait until later due to backwards compatibility.
Joe
No, hardly not. Will remove it and commit later.
Joe
Hello Guys,
I would say that this is rather region specific so I suggest following a global setting like the one selected by Janusz.
We simply put the setting in config.php. That is my opinion.
Joe
This has been fixed and committed to stable repo. Thanks @kvvaradha and @apmuthu.
A fixed file can be downloaded here and replaced.
Joe
Oops! Thanks @kvvaradha for detecting this. Well it did no harm and the conversion is done immediately after the open balance call.
But it should not be here
Committed to stable repo.
/Joe
@Braath Waate,
Are you suggesting a correction in the core? I have some problems following this thread.
Please be a little more specific if I should change something in the core. Thanks in advance.
/Joe
Hello,
Janusz wrote these routines. He is informed about this. He is busy at present, but will fix this asap.
Joe
Hello all, and especial @notrinos.
I have been looking at your work, @notrinos, and it looks very good. I think it should be implemented in the core for release 2.5.
I only have one suggestion. Instead of using the reporting folder I would rather like to make this folder inside the new dashboards folder. and also the includes folder. f.i.
a folder called: widgets and inside this folder all the widgets and the includes folder.
The reason for this is that the reporting folder is more addressed to the reporting system.
We could use all the widgets or some of them in the core. I haven looked at this in detail yet. This is a matter of taste.
I guess you have taken all the current widgets, right?
I will have a talk with Janusz, about merging the stable 2.4.6 into the unstable version and call it 2.5 Alpha, and then we can implement your dashboard variant, is that ok @notrinos.
Janusz has been working on your HRM, but I don't know how far he is, but I think this HRM should also be in the 2.5. I guess it need to be 'merged' with your new ideas as well.
Thank you all for your coorporations in this matter.
/Joe
This has been fixed and committed. Thanks @anoopmb.
We will see later if the function is needed or not.
/Joe
No, but we have been busy fixing an SQL Injection problem.
Give me some time to evaluate this. It seems good.
/Joe
Ok, but the 'STRICT_ALL_TABLES,NO_ZERO_IN_DATE' was implemented by Janusz to prevent SQL Injections. As I told we fixed a lot of sideeffect errors, but your error was another one.
I will ask Janusz to do something about this.
/Joe
@Braaht Waate.
Which version of PHP do you use? And did it fix the problem?
Janusz did a security update due to some report of SQL Injections. We have taken most sideeffect errors but you might have run into another one.
Joe
This has been fixed and committed to repo. Thanks @kvvaradha for detecting this.
A new file for replacement can be downloaded here.
Joe
Hello,
The 2 core COAs have now been redesigned a bit and are now syncronized. Only that the demo variant has the demo data..
I have tested both of them, and it seems to work fine.
Committed to repo.
/Joe
No, the dashboard tables should not be there.
Well if users make a backup they will see the '#' as a comment specifier.
Will make a rerun later.
Joe
Hello again.
Only en_US-demo.sql needed update of the 2 core. It was done by moving 2017 to 2018 (search and replace). Then creating a new year 2019-01-01 to 2019-12-31. And setting the Company to this year. Then a couple of transactions were made.
This is all we can do. Remember things are very close mingled in the database. But this is good enough.
The en_US-new.sql was ok as is. The fiscal year was set to 2018-01-01 to 2018-12-31. I think this is ok, for when you start a new company you will often make an opening balance on the end of 2018. And then create whatever new fiscal year you need.
All the other COAs from the repo only needs a new fiscal year, I guess.
But Janusz will do some adjustments to the 2 core COA's due to SQL security injections. And of course also to the repo COAs.
The new en_US-demo.sql has been committed to repo. Can be downloaded here if needed.
/Joe
I will fix it manually this time for the two charts we have in core, but if you are keen fixing it your way, you are welcome to try.
We do have a lot of charts that need update.
Joe
Yes, it is a matter of search and replace.
Joe
FrontAccounting forum → Posts by joe
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.