Field level security

kenl
kenl Member Posts: 182
edited 2013-08-22 in NAV/Navision Classic Client
Hello,

How can we setup field level security ?

For example, I would like to disable a field on Sales header for some users. How can we set it up?

I don't find field level setup in user->Roles setup :(

Best regards,

Ken

Comments

  • kine
    kine Member Posts: 12,562
    No in standard, you need some module for it...
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • kenl
    kenl Member Posts: 182
    Hello kine,

    Which module we need for field level security?


    Best regards,
    Ken
  • kine
    kine Member Posts: 12,562
    :-) I have no exact module in my mind... you need some module... (there is no standard module)... Our company have such a module prepared (Navision 3.70>) - Insert, Modify, Delete permissions on fields...
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • DenSter
    DenSter Member Posts: 8,307
    You can buy a field level security add-on from Lanham. It works ok, but you have to know exactly how it works before you start using it in production. Also it doesn't allow you to easily take away security, so if you use it, start out with one table only, get the hang of it and incrementally add additional tables to it.
    Daniel Rimmelzwaan
    RIS Plus, LLC
  • wonmo
    wonmo Member Posts: 139
    Create a function on the subform where you set the editability on the field based on userid and call it on the OnOpenForm trigger:

    CurrForm."some field".EDITABLE(USERID IN );
  • kine
    kine Member Posts: 12,562
    Our solution do not modify existing objects (only CU 1 :-) and you only configure which role have which permissions on which table and field.
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • pri_1_ranjan
    pri_1_ranjan Member Posts: 67
    if the field level security is related to data procurement ; such that one person have the acess to certain kind of records and other do not then then i would suggest that using resposibility centre will be a good idea
    /PDR
  • Shenpen
    Shenpen Member Posts: 386
    It is IMPOSSIBLE to not modify existing objects. EDITABLE and VISIBLE can only be coded into the form itself.
    Do It Yourself is they key. Standard code might work - your code surely works.
  • nelson
    nelson Member Posts: 107
    It's not impossible if you know how the Change Log functionality works... think about it.
    Nelson Alberto
  • kine
    kine Member Posts: 12,562
    Shenpen wrote:
    It is IMPOSSIBLE to not modify existing objects. EDITABLE and VISIBLE can only be coded into the form itself.

    It IS possible... \:D/ as nelson said... base is Change Log functionality... (but you do not need this granule)...

    I know about what I am speaking, I developed such a module for 2 months... O:)
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • Shenpen
    Shenpen Member Posts: 386
    Ah, you mean the global triggers? That goes table (recordref) level, not form level, and it means you can make a field noneditable, but cannot make it invisible.
    Do It Yourself is they key. Standard code might work - your code surely works.
  • kine
    kine Member Posts: 12,562
    Yes, I spoke about Insert, Modify and Delete permission, not about View or select permissions... :-)
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • Shenpen
    Shenpen Member Posts: 386
    Ah, but that's the real point!

    If a field is there, but the user gets error message for modification, then he will rightfully ask "If that field is not to edit for me, then why isn't it gray?" (uneditable) Don't forget the old usability rule: the computer must not ask questions it could figure out for itself.

    And actually the important thing is field invisibility, for two reasons:

    1) Users are really scared about how much fields Navision has. Psychologically they feel the software expects them to answers hundreds of questions f.e. all the fields and tabs on Sales Orders or Customer Cards, and a typical company uses 10% of them. And if they don't need it, why are those fields there? So what we would really need is configurable invisibility (and automatic change of field orders, and moving fields between tags).

    I made a Perl script that codes configurable invisibility into forms exported in TXT, but auto-arranging fields to fill the gaps and auto-moving them between tabs if a too big challenge... so it seems we are stuck with those annoying Design Form, Save As, "Customer Card for Warehouse Employees" - implementation processes...
    Do It Yourself is they key. Standard code might work - your code surely works.
  • kenl
    kenl Member Posts: 182
    Hello All,

    Thanks for all of your information.

    But I am talking about "Field" level security. So no much about Insert / Delete (These two would be "Record" level security)

    What I am looking for is, Field Level Security includes
    -visible
    -editable

    Eg.
    On Sales order, statisitc form, I would like to hide the "Profit %" for some users.

    On Sales line, hide the "Cost Price"... etc

    I know that we can modify the existing form to set Field.visible(). But I would like to know is there any better way to do it? I want to avoid changing so many forms for this Hidden fields task.

    Thanks,
    Ken
  • kine
    kine Member Posts: 12,562
    There is no way for this now... may be in some next version... ;-)
    (without changing the forms)
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • Savatage
    Savatage Member Posts: 7,142
    I guess he ruled out
    http://www.lanhamassoc.com/securitymgmt.htm
    as an option mentioned earlier?

    sometimes you have to pay the piper if you want to dance with the pretty girl :D
    Harry Ruiz
    http://www.BiloBeauty.com
    http://www.autismspeaks.org
  • eYe
    eYe Member Posts: 169
    Hi,

    I also wrote field level security solution for a customer running NAV5.0

    The security check runs perfectly. I modified GetGlobalTableTriggerMask() to ensure that for the appropriate table it execute the OnGlobalModify (they are only interested in modification of fields)

    Then in OnGlobalModify I call my function to test if the user has permission to modify a field.
    For a user not having permission to modify this field it displays the error correctly and rolls back the change.
    But now on each read, write on anything, it displays the error message. Switch debugger on, but it doesn't stop on an error.

    Added before my function call in OnGlobalModify:
    CLEARLASTERROR


    But still the issue persists.

    Anybody have a suggestion please?

    Regards
    Kind Regards,
    Ewald Venter
  • eYe
    eYe Member Posts: 169
    Works perfectly on NAV2009R2... :|
    Kind Regards,
    Ewald Venter
  • kabroco
    kabroco Member Posts: 111
    You can use easy security with "FLADS " for this, a tool from mergetool. See website mergetool.com
    also instruction film on youtube.

    You need a license for this, but the customer can set their restrictions as he pleases.

Categories