I have re-send it to contribution@frontaccounting.com
2 01/03/2012 09:01:00 am
Topic: Secure Transfer of Password (2 replies, posted in FA Modifications)
Hi joe/itronic,
I've sent a code in contribution@frontaccounting.com for a secure transfer of password, there seems no reply, have you look at it?
Regards
ASRIA
3 10/13/2010 10:02:16 am
Topic: Procedure in Changing Password is not secure (0 replies, posted in Wish List)
I wish that in "Change Password" menu, an existing password is required and authenticated before the new password is accepted by the program. This will avoid the case where a user leave the system without logout to go to get some cookies and immediately some other people come to the screen and change the password. Although the system will automatically logout after some time, requiring existing password to be entered will make FA more secure in user point of view.
4 10/09/2010 05:24:42 am
Re: Is there a limit to customers that can be created. (4 replies, posted in Accounts Receivable)
Thanks for the reply, I am thinking of using Citrus DB (https:/sourceforge.net/projects/citrusdb/) as a replacement for customer management because it have the functionality that I want. But the problem is that, Citrus DB do not have inventory function. I am thinking that instead of maintaining two databases and sync between the FrontAccounting and CitrusDB, its better to perform data conversion on the lower level, ie., Citrus DB convert to FrontAccounting table when "saving" data then the otheway round when Citrus DB "reading" from FrontAccounting. That way, I don't have to bother with sync. Then there is the issue of customising Citrus DB to handle inventory item.
Does anyone have any experience using Citrus DB?
The other idea is that, build a new module for FrontAccounting and use Citrus DB code as guideline. That would be a "cleaner" thing todo, but it may take a lot of time.
Thanks again.
ASRIA.
5 10/06/2010 07:03:04 am
Topic: Is there a limit to customers that can be created. (4 replies, posted in Accounts Receivable)
Is there a limit to number of customer that can be created, assuming that I have 5000 customers. Will there be a problem with that number of customers in FA? I'm going to create a module that allow customers accessing their transaction history, what is the best way to do it in FA. I'm planning to create one user called CUSTOMERS that will be used as login for all of the customers to login to FA, at the same time, they will needed a username/password that is going to be place in different table but pointed to customers record in FA database. Can FA cope with 5000 login at the same time? Another idea is to used different open source membership program, but performing sync with FA data, but take a lot of work. Any ideas?