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 cambell
@s4m3shms I'm working on refactoring the tests and ensuring consistency in GET, POST and PUT for all endpoints based on your feeback (with tests).
@apmuthu. Thanks! Fixed in https://github.com/cambell-prince/FrontAccountingSimpleAPI/commit/d3d183aa733d562e2de8536bd8f7ce3a672ae781
A new release of FrontAccountingSimpleAPI is available here:
https://github.com/cambell-prince/FrontAccountingSimpleAPI/releases/tag/v2.4-1.3
This includes support for json sent in requests using Content-Type: application/json with json encoded data in the body.
@s4m3shms I've just got the api working accepting JSON input with a Content-Type: application/json, its only working on my machine right now. I'll code a unit test and hope to ship a release tomorrow.
@s4m3shms You'll need to use the content-type: application/x-www-form-urlencoded and ensure that your data is form encoded (not JSON). This is how the SimpleAPI has always been since its beginning.
The unit tests show how to do this with Guzzle in php. .NET can also do this easy enough I think.
@fernando_bender The font-size is simply the body font-size of 11px. So body { font-size: 14px; } in default.css would make it bigger for example.
col-sm and col-md set media break points for different devices. e.g. sm is for phones and md is for tablets. This controls how the controls and labels are layed out e.g. label side by side with control for desktop vs label on top of control for phone.
@s4m3shms I have started some documentation here but it is a long way from complete. It is auto generated from comments in the code and I haven't the time to do that all in one go. But its a start.
In the mean time you can learn how to use the SimpleAPI from the tests that are in the source (but excluded from the package).
https://github.com/cambell-prince/Front … r-cp/tests
As an example, the sales test shows how to list, create, update, and delete a sale.
If anyone wants to see the source annotations for the documentation you can have a look at the feature/docs branch in GitHub.
@apmuthu Thanks for testing.
Here are some quaint errors:
0::Set.php:72:[before upgrade] Redefining already defined constructor for class Slim\Helper\Set 0::Log.php:304:[before upgrade] Redefining already defined constructor for class Slim\Log
These errors have been fixed in Slim issue 419 back in 2012 with this commit. However, this fix was included in Slim v3.x which claims to require php >= 5.5.
Options would be to upgrade to Slim 3.x requiring php >= 5.5 or stay with Slim 2.6.x and document for those that would want to fix this issue. I'm not wanting to backport the fix simply to maintain compatibility with a very old version of php.
Line 163 of vendor/slim/slim/Slim/Helper/Set.php should not have any return value.
Fixed in Slim 2.6.3 which I'll use in a future release of the module.
Is line 111 of vendor/slim/slim/Slim/View.php okay?
Should Closure be preceded by a slash?
Fixed in Slim 2.6.3 which I'll use in a future release of the module.
Line 18 of src/Purchases.php should be like all the others:
$body = array();
That would be php 7 features leaking in. I'll maintain php 5. something compatibility and make it consistent with the other modules. Purchases is not yet feature complete. There's no endpoint yet defined for it.
@apmuthu I've made a new release here:
https://github.com/cambell-prince/FrontAccountingSimpleAPI/releases/tag/v2.4-1.2
I've also updated the Travis CI tests to test against the official FA mirror on GitHub.
@apmuthu Thanks for testing this and providing your feedback. I've made some improvements to the packaging along the lines you suggest.
@cambell: please provide one that is stripped of composer and unit tests so that the end user can deploy and extend without a steep learning / confusing curve. As Slim v2.x can be used without composer by using it's internal AutoLoad feature, all vendor dependencies can be eliminated.
I like using composer for development. I'm not wanting to remove it. However, my goal is the same as yours - that the end user can install and deploy easily. The goal is for users to be able to download a packaged release and put it in the folder. I agree that the packaging in my 2.4-1.0 didn't achieve that goal.
The unit tests were not present, however PHPUnit was. I've improved the packaging to exclude development dependencies from the vendor folder.
Your release does not work.
Yes that was sadly true. Thanks for taking the time to test, that's much appreciated.
You have removed the class SessionManager() in the session-custom.php (not updated to reflect this core commit) but referred to it in the code at line 46.
Sadly I've coded this against my version of Front Accounting which includes this pull request from January 2016 which separated out the session functions from the core session code. This reduces the copy / paste and makes implementing both unit tests and the REST API easier. I'll leave it to the FA community to solve that. I can say that if you use the same version of FA that I use it will work for you. I guess you can copy session_utils.inc into the folder and amend the pull-request.
Also you are referring to a hardcoded non-existent file/folder name in the config_api.php file: _frontaccounting
You are referring to $rootPath but have initialised $rootpath in config_api.php - in fact it is sufficient for it to have just:
define('API_ROOT', '.'); define('FA_ROOT', './../..');irrespective of whether it is hosted on Windows or on Linux to alleviate the effect of the DIRECTORY_SEPARATOR.
Yes, that's needed to make the Travis CI builds work. If you can think of another way of having Travis test a module without this technique do let me know.
You will want to add in the following into an .htaccess file:
RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^ index.php [QSA,L]
I've included the .htaccess file in the packages.
Your api module just does not work. Tested in FA 2.4.3+, PHP 5.3.1.
Well, it doesn't work for you. It works for me, and it works on Travis. There's the session_utils issue which can be solved by using my version, accepting the pull request from Jan 2016, or copying the session_utils file into the REST API folder.
@s4m3shms I've updated the Simple Rest API to support FA 2.4.x. There's a release at this link:
https://github.com/cambell-prince/FrontAccountingSimpleAPI/releases/tag/v2.4-1.0
It includes Slim and everything it needs to work, you should be able to copy it in to a folder such as modules/api and it should just work.
I use the Chrome extension Restlet Client to test REST API's.
@boxygen. I don't have that problem myself. However, I can see that rep107.php does have the ability to send multiple emails if the from invoice number and to invoice number are not equal. The recurring module sets these equal so it should only ever send one email for each invoice generated. Do you have any other modules loaded?
@boxygen. Yes, I'm using the recurring module in production. I'll have a look. I'm pretty sure that's not happened to me.
@boxygen that's kinda funny. Most of the recurring module is a copy and paste of FA core. I hear what you're saying, I remember teaching Object Oriented Programming to beginners at a community college in the '90's. The students found object oriented concepts difficult to grasp.
The recurring module is a little complex - but, I think less complex than the existing FA implementation of a similar feature.
@apmuthu Increasingly in modern web development there is a difference between what you code and what your ship / deploy. e.g. If using bootstrap you might code using scss fragments that are built (webpack, gulp etc) into a single css file that is shipped. Similarly for javascript, and also for any php dependencies.
I've been using composer, npm, webpack, bower (when that was something) for many years now. There are always issues with anything, but I've found the benefits to be well worth it.
The object oriented paradigm and auto load have long been core features in php for more than 10 years now. It would be nice to see FA move with the times :-)
@kvvaradha your method doesn't work if you are wanting to use a standard report from within a custom module. The $path_to_root should be set only once, the report never checks if its defined and overwrites it with an incorrect value. The __DIR__ is correct in both cases.
Personally, I don't think that the path to root is robust (given that it should be set only once from the point of entry), I'd love to see things switch to a more modern class auto load system, and would be happy to code that for the project. It would probably take a few weeks if it was just me.
I've been fixing it as I go. I'm running PHP7 in production.
The intention with the auto create checkbox is that some other cron job could auto post sales orders marked with the auto create flag. I've not integrated that with FA cron processing yet.
You will also need this patch to FA core for it to work properly:
https://github.com/cambell-prince/frontaccounting/commit/f9bee2f78bb6881cecc93b47145d9cf70345dca7
The PR queue remains too long to submit a new one.
I just published v1.3 which has a 'show all' feature. This brings it up to date with the current master branch.
I suggest you download one of the released versions:
https://github.com/saygoweb/frontaccounting-module-sgw_sales/releases
They have all the needed files. The source code repo does not have the composer install files.
Thanks. Given the extent of the changes made to the core its a little time consuming to keep this in sync with mainline FA development.
@boxygen You might be interested in my sales module https://github.com/saygoweb/frontaccounting-module-sgw_sales This provides an alternative recurring invoicing system that integrates with the recurring entry with the sales order entry screen. I use this for a hosting business.
@davidkumi Well done. :-) Thanks for sharing. Here's some comments that would make it even better:
- Instead of "if $keep && $delete" you could do "if !$keep error if !$delete error" That keeps the error handling consistent and near the top of the module effectively saying 'if the input is bad, error out early before proceeding'.
- There's no checking on the input data, so you can easily do sql injection here. But, for a one of use, not to worry about that.
- $result isn't used in the UPDATE or DELETE queries, so you don't need it. Just call db_query(...).
Its not too far off a plugin. Just need to add the menu location and a bit of plugin boiler plate and it would be a plugin.
Yes, I have some php7 fixes, and I have FA working on a server with php7 with no problems now. I just checked, those fixes are not in the current 2.4.x master branch.
Sorry, I mean the additional_headers parameter, not the body. From the php manual:
"Note: When sending mail, the mail must contain a From header. This can be set with the additional_headers parameter, or a default can be set in php.ini. Failing to do this will result in an error message similar to Warning: mail(): "sendmail_from" not set in php.ini or custom "From:" header missing. The From header sets also Return-Path under Windows."
The content type header should be honored if the mail server supports it.
FrontAccounting forum → Posts by cambell
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.