Currently the only access control in Ledger is a single "administer ledger" permission. This essentially means that it can only be used by a single individual or organization.
Ideally, Ledger could be used by any number of users within a site, each with their own sets of accounts independent of one another.
To achieve this, a form of account ownership is necessary. The easiest approach is to add a "uid" (user id) column to the Account entity, which would indicate who created, and therefore who "owns", the account.
This would also enable more fine-grained permissions for accounts by user (ie: [view/edit/delete] [any/own] accounts).
It would also require reworking the UI, so that users would only have access to their accounts. Perhaps it makes sense to move most of the UI that is currently in /admin/ledger to /user/[uid]/ledger or /ledger/[uid] (with a default of /ledger for cleanliness -- similar to /user). The Ledger settings stuff should remain in /admin/ledger/settings or /admin/ledger, but perhaps there would also be some user-specific settings down the line.
It seems that Account ownership would cover most situations, but should we also consider adding a "uid" column to Transactions? What about Account Entries? I can't think of any use-cases for that off the top of my head (that wouldn't already be covered by user-owned accounts), but I'd love to hear thoughts.
Comments
Comment #1
zulfierken commentedAdding uid to the account is great idea. With this, each user will have their own bookkeeping software. At the other hand, there will be thousands of accounts (I am not sure this is a good or bad thing for may case.)
To describe my usage:
1- There will be payroll, cash .... accounts for each user (Creating one account for each student will increase the number of accounts to thousands.)
2- Credit and debit user accounts with adding transactions. (From user to user or from admin to user as double entry transaction taken from user 1 given to user 2)
3- Users can view their accounts but cannot do anything.
I think there is a difference between the target of this module and my expectations. But code difference is maximum %5. I do not think that creating a fork to cover this difference is nice idea.
If you add uid in account table, I can create accounts per user programmatically. Later, I can give view only access to users. Create necessary forms to transact money and achieve my goal.
About adding uid to transactions and account entry;
I know that writing data again and again is a bad idea in programming. But If you are dealing with money you have to double check or triple check. You have to know which user added the data when the data added and if changed when. If one data is deleted by mistake, other data must be enough to recover data. Therefore, I would suggest to add at least these fields to both transaction, account and account entry tables. If a user delete the account or transaction. It would be possible to understand which account entry belongs to which user with looking at uid. Additionally, it will be possible to validate account entry with validating uid of account entry, transaction and account. It will become more secure in terms of hacking and changing the url.
Comment #2
m.stentaI added a lengthy response to your other post, which is worth reading if you haven't already, or if someone else is reading this thread later: http://drupal.org/node/1510414#comment-5817448
I agree that this module isn't exactly what you're looking for, but I think there is definitely potential to leverage Ledger to achieve what you want. It would just require another relationship type to represent transactions between two different users, I think (see my other comment for more info on that too).
In regards to your thoughts on double (and triple) checking... I agree 100%. In order for a bookkeeping system to be reliable, it needs to have a good way of tracing all activity. I had given this some thought before, and one idea that came up was a built-in logging system. So whenever anything happens in Ledger, it is recorded in a log that can be reviewed later. The log would need to be separate from any entities, otherwise there would be the risk of losing log data if the entity itself is deleted. I made an issue for that task so it can be discussed separately: #1512538: Activity log
Comment #3
zulfierken commentedYou are definitely right. I love how ledger works and like you said, with minor changes it is possible to record both money transfer and account entry. For money transfer and payroll, I am planning to write a sub module. Maybe, I will fork the account entry module as user account entry, and I will write a new user transaction module where people can choose from which user's account to which user 's account money will be transferred. This is the first part of my needs, and I think with a submodule I can use ledger to achieve this goal.
At the other hand, currently I am using quicken to keep my accounting information. Sometimes I need to know what I paid to which company for a certain product. Sometimes I try to find where I am spending my money. I am transferring money from my bank account to cash account or expense to income but, I have to note down where did I spend or where did I get the money.
To achieve this goal, I use payee (the person that I paid or received money) category and tags.
I want to use ledger and at the end of day, I will transfer account entries to quicken with a reference number (account entry id)
My plan about using website together with ledger is:
1- Adding each customer company or person that I receive or pay money as user. ( Most probably I will use party module or core_crm to store contact information)
2- Recording each transaction that I paid or received as account entry (transaction). Adding the payee information, pdf of invoice and receipt.
3- Adding the items that I bought or sell to drupal commerce database as product (or fee or inventory or asset I love entity :) ).
3- Creating reports that will help me to figure out: From which company did I buy, digital copy of receipt, information about the product that I bought.
I know that this need submodules to connect crm(http://drupal.org/project/party or http://drupal.org/project/crm_core), drupal commerce and ledger. This is the ideal solution for me and it is my target.
For other people, I am sure that they would like to know and filter where did they spend money and how much did they get from A or from B. To achieve this, there must be extra fields about uid or contact id or customer id. Best solution is creating a user interface where people can add fields to the account entry entity.
Another usage scenario is liability. I am going to collect or pay money to others in the future. If I am going to add this, I should know who will receive or pay the money again, a payee field is necessary. (It is very difficult to filter with using description field)
I think adding such fields will make ledger flexible. People can get detailed reports. Anyway, thanks for this great module :).
Comment #4
m.stentaI agree that making Account Entries fieldable should be under consideration. I've created a ticket for discussion: #1514940: Fieldable Account Entries
In the future, please try to keep individual tickets focused on their specific purposes (this ticket is focused on access control and account ownership). If a related ticket doesn't exist, feel free to create a new one! Thanks again for the comments and use-case examples! Keep them coming (and keep them organized)! :-)
Comment #5
m.stentaI decided that I'm going to add a new entity type called "Ledger Book" to handle account ownership and access control. See #2046231: Ledger Book for more information.
Closing this ticket because it's a lot of support discussion, and the new issue will be more focused.
Comment #6
m.stentaRelated: #2185707: Access control per entity and operation