Enable multi-user editing
Allow multiple users, in a business to access the database at the same time so that multiple transactions can be entered or updated simultaneously, and do so with remote access capabilites like Terminal Server (Windows) or X-Term sessions (Linux/Unix) .
This is a feature in many commercial programs and this is exactly why many business users of such programs are not using GnuCash.
If GnuCash wants to secure donations from the business community beyond the home or individual operating as a business, this feature will make GnuCash extremely attractive to a market that routinely pays $3,000 to $5,000 for products lke Quickbooks Pro with $850-$1,000 per year support contracts.
Concurrent multi-user support has been part of our long-term goals for a while now:
Time to update the status of this feature request…
Note it still says “long-term”, which currently means several years ahead of us.
AdminGeert Janssens (Admin, GnuCash) commented
As a gnucash developer I can tell you multi-user support is still a real design goal for gnucash and one all active developers would love to reach as soon as possible.
The necessary core rewrite however takes much more time than anticipated and contrary to what some suggest in the comments here hasn't attracted loads of extra interested developers. It's essentially hard work and currently done by less than a handful of volunteers. So if you are interested in contributing you're most welcome to let us know via irc or gnucash-devel and we'll work out what you can do. Note we're currently close to starting our beta-release cycle for gnucash 2.8. It will take us the next couple of months of our time to stabilize this big release so core refactoring will only be resumed after that.
I think they are concerned with hosting. The approach I would use is, make the software get served from whatever host the end user wants to use, such as sharepoint, google docs, dropbox, etc. And what maybe they can do is lock each transaction while it is being updated, and release it once it is saved. This would allow multiple users to no access the same record at the same time. Plus will eliminate the need for Gnucash t set up servers to handle the backend needed for multiusers.
As I read the FAQ about SQL support, it sounds like the code base might be moving slowly toward this goal of multi-user support. I hope that is the case. I would benefit greatly from being able to make a change in the sql tables and have that propagate back into any instance of gnucash that might be accessing the database (i.e. model-view-controller). This would open the door to web-based view's being developed that can access a gnucash model running on a server somewhere. That would be awesome!
It isn't useful for just some users. It is vital for most small businesses, and mine is no exception. Multi-user support would also benefit many home users. I understand your code base is overly complex, mixing c, scheme, emulated oop and c++. It doesn't follow nowadays' best practices too. I guess a complete rewrite is highly recommended, though painful. But I'm sure there would be plenty of community support to feed a rewriting fork, and there are plenty of frameworks that can easily solve those dependencies and give it true cross-platform capabilities, allowing us to focus on the functionalities rather than system/lib/GUI stuff. I have a strong background on every languages GnuCash uses today, but I'd prefer to use a RAD environment. The Lazarus project (www.lazarus-ide.org) is one of those things, for example. Using Free Pascal, an object pascal derivative, you could cut that long functional catch up phase to a couple of months, and the resulting GnuCash would be much more powerful.
Anyway, I'm not GnuCash's mentor, but I do love it and would like to see it evolve. My time is really scarse, but I'd love to help too! :)
I am a small business user - staff of three and have to use Reckon (Quickbooks) as we need to run Multi Hosting, one by our accounts person and a second machine in our despatch area. We also run a third machine for enquiries. GnuCash would certainly knock Reckon if it had similar abilities to allow multi users.
Just save the file as .sqlite3 to your google drive. then don't open the program at the same time. happy multi-users :D
going further on multi-user gnucash enabling ---> we can add columns created_by and modified_by to all tables and allow editing of records only to the user who created it or the admin ... triggers can be used to add data to the new columns and this will save programming effort ...
but i still feel even with the current architecture multi use would be possible ... probably beginning with what i commented below ... need some more comments from developers of gnucash to post more ideas on this ...
CSTIM ... is it illegal to start a same to same copy of gnucash project even if it is open source?
well i think multiuser access could be possible with database server at backend like MySQL ...
all that needs to be done is to use InnoDB tables and the transaction isolation level to Serializable ...
yes it would slowdown things but to start with this could be a safe option ... along with only insert allowed from data entry stations and edits to be allowed from only one station ...
It's obvious that after 10 years (or more) of people telling GNUCash that multi-user is what is necessary to make it a useful program for businesses that this feature is not going to happen.
I suspect the codebase is too antiquated in design to be able to support this feature without completely re-writing the codebase.
A new team needs to fork this project or start a new project with the proper design parameters accounted for right from the beginning. Instead of just trying to stretch a checkbook-helper program into a real business program.
Hello! I use MySQL (it very much cool! And quickly!). Whether it is impossible to make the multiuser access through a database? :)
Back in 2005 :
Derek Atkins wrote:
>> Right now there's not a good multi-user gnucash solution. You can
>> have multiple users serially use gnucash, but not simultaneously.
>> We're working to recitify that situation, but that wont be solved
>> until at LEAST the next major release.
Many would like to see this feature and it would make Gnucash much more viable to businesses,
I would love the hear the latest news about this from the Gnucash team.
Multi-user please !!
Pablo Scolpino commented
This feature and the architectural changes it entail are extreamely interesting. i would be willing to volunteer developer time.
Hideaki Shiina commented
I quite agree with Jorg.
I think Gnucash should be server.
Jorg Bliesener commented
I have no doubt that this suggestion represents a major issue. However, I consider it more than just "nice". It's a MUST for gnucash to evolve. This should be complemented with a good API that allows for alternative user interfaces (AJAX,Static Web, Command line, ...), effectively introducing MVC concepts.
Not to add project creep... multi user will allow for POS.
There have been a few startup's that i could have suggested GnuCash but multi was a requirement.
Vladimir Bashkirtsev commented
I would agree that such "feature" will make us see GnuCash 3. Current code base clearly had no intention to become multi-user system. But I will agree with OP also: this feature is REQUIRED for GnuCash to move onto serious business scene.
My business is small but I'd like to have GnuCash running on my notebook and on my desktop in the office simultaneously. I found it relatively simple: as I am only user I can reload book from open DB over VPN and ignore warning that DB is already open. So it does the job but if I have someone else working on the same DB in my office it may throw things out of balance quickly and may be even corrupt DB.
Admincstim (Core Developer, GnuCash) commented
I'm not opposed to this suggestion, but I'd just like to add that it will require an almost complete rewrite of gnucash. Subsequently, this rewrite will probably happen in another programming language (C++, Python, Whatever). And this rewrite will probably take 12-18 person-months until it reaches feature parity for the main business features.