#914 Permissions not fine-grained enough

1.5
closed-postponed
nobody
None
1.2
5
2015-10-17
2013-12-03
No

(From a list of issues sent to the development list by John Locke)

Also, have not gone through permissions in detail but do have some challenges around permissions in 1.3 at least, and am assuming are still in 1.4. Specifically, I'd like to be able to set up an admin to handle AR and have them be able to pull up cash receipts without being able to see payments or AP. The Cash permissions don't seem to be able to separate between AP and AR transactions -- all become visible when adding cash permissions. (I can see this being relevant for AP folks, too).

We had discussed at some point simplifying the permissions screens to show a lot fewer but more appropriate permissions. I think having the fine-grained control is good, but it's overwhelming -- and yet here's a case where it's insufficient. Maybe we can define a few different roles that can aggregate appropriate permissions, and then have a more detailed screen (eventually -- certainly not necessary now) for fine tuning.

Oh, and another case where permissions are insufficient -- different roles need access to different files. E.g. AR probably needs access to files attached to customers, orders, etc but not employees. HR needs access to files attached to employees -- but most other roles should not have access to these.

I'm thinking these basic roles as a starting point:

AR -- access to customers, AR transactions, receipts, AR vouchers

AP -- access to vendors, AP transactions, payments, check printing, AP vouchers

Bookkeeper -- data entry on AP/AR/GL, reconciliation,

HR - employee records, files on employee contact records

Owner -- transaction approval, batch approval, draft approval, reports, HR/Employees, Users

CPA -- read-only access to all reports, AP/AR/GL detail, Close books

Cashier -- POS

I'm sure there are many others, but those are the gist of what comes to mind...

Discussion

  • Chris Travers

    Chris Travers - 2014-01-21
    • Group: 1.4 --> 1.5
     
  • Chris Travers

    Chris Travers - 2014-01-21

    Moving this to 1.5. Reason being:

    this is the way things work in 1.3, and can be adequately handled by an addon in 1.4. I agree there are legitimate issues here but coming up with a really good, graceful solution is a great deal of work and not sure it is worth possible significantly delaying a major branch for given that it is not a regression.

     
  • Chris Travers

    Chris Travers - 2015-10-17
    • status: open --> closed-postponed
    • Version: --> 1.2
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks