mibuso.com
Home› NAV Three Tier
Options

Permission Sets Question

Markus_HMarkus_H Member Posts: 8
edited 2015-08-05 in NAV Three Tier
Hey there,

I have the following requirement and no idea at the moment, how to do this "efficiently" - hope someone has a good idea :-)

There are users out there with very limited permission sets - they can mostly only read data, using the windows or web client. In addition, those users should be able to post documents in a web service context (using an external web application that communicates via page or codeunit web services).

Is that possible and how would you do this?

My only idea so far: Using 2 users (one with limited permissions for the windows/web client and another with posting permissions for the web service - but can you prevent the second one from using the windows/web client?)

Thanks a lot in advance,

Markus

Comments

  • Options
    kelseykong@hotmail.comkelseykong@hotmail.com Member Posts: 86
    Markus

    Do you mean the user is not allowed to post documents using windows or web client, but only with a web service. If this is the case, would you please let us know the purpose of this requirement?

    Thank you.

    Li
  • Options
    Markus_HMarkus_H Member Posts: 8
    Dear Li,

    consider the following scenario: There are users that only check and approve invoices at the customer site and therefore have only very limited permissions using the win/web client - especially they should not be able to create and post new invoices there. We have a web based approval workflow, in whose last step those users check the invoices and perform their approval. After having successfully approved an invoice, it should get posted automatically. Any occuring posting errors must be presented to that user because then he has to send the invoice back to someone who must correct it.

    So those users should be able to post invoices via web service only and not from the win/web client. :)

    Regards,

    Markus
  • Options
    kelseykong@hotmail.comkelseykong@hotmail.com Member Posts: 86
    Markus

    Just to throw my two cents, can hiding the post related button to certain permission group(s) work in your scenario?

    The permission group can be defined in a new field, so that the client has flexibility to define which groups should be restricted from viewing those post buttons.

    Li
  • Options
    crgarciacrgarcia Member Posts: 7
    I don't think it is possible, and in general I don't think it is a good design that a server behaves in different ways depending on the client type.

    If the process cannot be done inside NAV, then a better solution would be that NAV ask the other system if that user can to do that operation.
    In other words, the system that knows the process, is the one controlling the constrains of it.

    If this is too complicated, a quick solution would be to add the functionality in a codeunit instead of in the page, so then the webservice call will be "hidden" from the win/web client. This still allows a user that knows how to use webservices to do the operation skipping the website. But the function will be only accessible via webservices

    Regards,
    Carlos.
  • Options
    Markus_HMarkus_H Member Posts: 8
    Hi crgarcia,

    I'm not understanding your approach completely. But as far as I understand, it doesn't matter if I use a page or codeunit for that. Fact is that all C/AL code is running in the context of the authenticated approval user, so when he clicks on the "approved"-button, a web service session is beeing opened in which a NAV function gets called which in the end triggers the posting methods. And everything happens in the context of the approval user, technically. Unfortunately there is no "runwithelevatedprivileges"-pattern in C/AL as it exists in SharePoint, for example.

    Regards,

    Markus
  • Options
    crgarciacrgarcia Member Posts: 7
    Hi Marcus,

    What I ment, is that a server should not have different behavior based on the client type.
    What you could do: when a user tries to post, then NAV should call your website to ask if that transaction for that user is allowed or not. Your website, that knows the workflow, is the one that should take that decision.

    If this is too complex, then you can try this:
    1. Give indirect permissions to write the table(s) to those users.
    2. Create a codeunit, and do the posting from there
    3. In the codeunit: Proprties -> Permissions add TableData TableName1=rim,TableData TableName2=rim
    3. Grant execution permissions to that codeunit to the users.
    4. Expose the codeunit via webservices

    This will make that users can only post executing that codeunit, which it is hidden from the UI

    Carlos.
  • Options
    Markus_HMarkus_H Member Posts: 8
    Hi crgarcia,

    unfortunately I have no separate website that "knows" my workflow and its users because it all gets configured inside NAV and we have only a bunch of webpages communicating through NAV web services with NAV.

    Using indirect permissions with codeunits was also something we considered. But this is not possible as we ship our solution only with permissions on TableData, Execute permission of codeunit "0" is provided in our base permission that every user gets.

    Recently we discussed giving those users, that should be able to post from the win/web client, a seperate flag on their NAV user that is checked in codeunits 80/90. Users without that flag will get an error posting from win/web client but will be able to do this in a web service context.

    Best thing would be an "impersonification pattern" (like in SharePoint e.g.), where developers can run parts of their code in the context of different users.

    Regards,

    Markus
Sign In or Register to comment.