Narrowing of G/L permissions possible?

c.bakker
c.bakker Member Posts: 13
edited 2008-02-13 in NAV/Navision Classic Client
Investigating the possibilities to narrow regular user permissions in Nav 5 I got a little bit a nasty feeling in my stomach.

Does anyone know wether it is right that users who must be able to post (for example) purchase orders must have at least Indirect Read permission for Table 17 G/L Entry?

I would very much like to avoid assigning Read permissions for Table 17 G/L Entry because this permission very quickly results in permission to see or estimate company financial figures and profitablity.

I am very curious how other people are approaching this nasty issue!
Choose a job you love, and you will never have to work a day in your life.
Confucius 500 BC

Comments

  • jonsan21
    jonsan21 Member Posts: 118
    Well, I always think that Navision is created in a very open approach, and the security system is not one of the best in the market.

    Is posting referring to Post Receive or Invoice?

    I'm quite sure if Post Invoice the Purchase Order, the permission should be there. You can try this download:

    http://www.mibuso.com/dlinfo.asp?FileID=357

    Rgds,

    Jon.
    Rgds,

    Jon.
  • kine
    kine Member Posts: 12,562
    If you want to post, you need to have rights to read the G/L, else NAV will not be able to find out the last entry no. etc.

    May be you can change the way you are posting and let NAS (Nav Application Server) post the documents. It means that user just check the document and mark it "for posting" somehow and the automatic process under NAS account will post it.
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • tinoruijs
    tinoruijs Member Posts: 1,226
    You could define a role which contains rights for forms all users may use. Add this role to all users.
    And next you define a role which contains rights for forms which can only be viewed by users who are allowed to see g/l entries.
    Tino Ruijs
    Microsoft Dynamics NAV specialist
  • bbrown
    bbrown Member Posts: 3,268
    https://mbs.microsoft.com/knowledgebase/KBDisplay.aspx?WTNTZSMNWUKNTMMYMXTYYKSWTLKQNNOXVYVPYPTUTSTYSUONRNMXRWXTKVYZRRPZ


    See article 857993 on PartnerSource. Look at item 8.
    There are no bugs - only undocumented features.
  • leugim
    leugim Member Posts: 93
    hi everybody

    creating or setting up roles is a hard work (...VERY HARD work ](*,) ](*,) ) because you must test each and every one of Navision options, buttons, menus... but you can set permissions to each and every one of Navision objects and get full control on what a user can and cannot view.

    you can set read permissions on TableData 17 G/L Entry and on Table 17 G/L Entry and no execution permission on Form 20 General Ledger Entries. this configuration will allow to read data when posting but denies access to G/L Entries...

    surely you will have to create new roles... be patient!!
    _______________
    so far, so good
  • jreynolds
    jreynolds Member Posts: 175
    Indirect permission to read the G/L entry should not be a problem. This does not allow the user access to the G/L Entry table except through objects (typically posting codeunits) that explicitly allow for read access.
  • c.bakker
    c.bakker Member Posts: 13
    hi everybody out there, thanks for your valuable response!
    Maybe not exactly the answers I hoped for but for sure they give usefull hints how to deal with the security issue.
    Choose a job you love, and you will never have to work a day in your life.
    Confucius 500 BC
  • Simpsoid
    Simpsoid Member Posts: 3
    In NAV 2013 R2 I still have issues with this. It seems for any 'posting' operation, including posting of Warehouse Shipments and Receipts, users need Read = "Yes" against tables 16 and 18 (G/L Account and G/L Entry). "Indirect" is not sufficient (I've tried again with recent rollup CU32).

    For this reason, as a company, we feel the need to remove the Departments menu and ability to modify their own role centres from almost all users, which is of course both a shame and quite inconvenient.

    I suspect many companies simply ignore this fact and hope(?) their users aren't too inquisitive, unless there is a solution of which I'm not aware.

Categories