Possible to Disable DI Security?

[Former Member]

Since the DI already allows me to read and write to any table in the database regardless of which B1 user I'm connected as (I was surprised, but pleased with this when I noticed it), I wonder if there's a way to tell it to also ignore security settings when using business objects like the BusinessPartners object. The reason I'm interested in this is because I want to remain connected as the current UI user so that when I create a document for example, the document is recorded as being owned by that user, and not owned by manager (also, I think it's much faster to connect as the UI user than it is to establish a separate connection). But I still want to be able to access objects like Business Partner via normal DI objects (even if the current user doesn't have permission to do so) and not resort to this other method that allows full access, but does not apply business rules.

Is there a standard way for DI-based applications to access DI objects with permissions beyond that of the currently logged-in user, but still be connected as that user so actions are recorded for the appropriate user?

[Former Member · Accepted solution]

I don't think the meaning of my question has been quite been hit yet. In any application, the code must have privileged access to the data. Even if a user cannot directly alter a piece of data, the application must be able to modify it on the user's behalf. I'm not very familiar with business logic, but assume, for example, if a payment is received for a particular invoice, the Balance Due of that invoice must be updated. The user cannot modify this field directly, but the application must modify it implicitly when the payment is received. This is what I mean by "privileged access" by the application. The current user cannot modify a field, but obviously the application must be able to update its value as part of another action.

I hope this clarifies my other examples. In a similar fashion, an AddOn may need to create a document when the user performs some other action. For example, the AddOn may need to create a Journal Entry when the user adds a record on some user defined form because the transaction should affect G/L. But maybe this user should not be allowed to directly create a journal entry. The Journal Entry can only be created by the AddOn in response to adding a record on this user form. So even though the user does not have permission to create Journal Entries, the AddOn must still be able to create a Journal Entry for them (and it controls all the parameters so the user cannot interfere with the business rules that the AddOn wants to apply).

The question is how should the AddOn create a Journal Entry (or perform any privileged action) if the current user does not have permissions to perform this operation. Should the AddOn create a separate connection as a different (privileged) user to perform the action? Should the AddOn circumvent the DI and update the database directly? The problem with logging on as a different user is that the DI now thinks that "manager" (the privileged user) is the one creating the Journal Entry, even though that is not the user responsible for the creation of the Journal Entry. I don't know if this is important for Journal Entries (maybe the user is not recorded) but in some other examples, it is important. In my other example of creating a document, the document has an owner. I don't want the owner of the document to be "manager" -- it should be owned by the user that caused the document to get created.

[Former Member · Accepted solution]

I've noticed another problem related to this. If the DI wants to read information from a business partner, the user must have Full Control of business partner in order to simply read the BP. Is there any way around this? Earlier messages suggested that the DI applies the same security that the UI applies, but that's not true. There appears to be no way to take advantage of read-only access to the Business Partner.

[AdKerremans · Accepted solution]

Hi Benjamin,

To use a business object through the logged on user MUST have full rights to that object, there is no other way. This is a known issue and is planned to be solved in SBO 2006.

As a temporary work around you can use a the recordset object to get your data.

Regards

Ad

[former_member185703 · Accepted solution]

Unfortunately there is no way by design which would give you what you want.

SAP Business One is in a way a closed system with interfaces around - your code does (as you know) not run inside the B1 code - it's running on the outside...

...and I don't see this changing in future.

DI API is seen more like "the application without GUI" in contrast to offering just something like simple "Data Access Objects"!

...remember e.g. the issue with decimals where DI API behaves the same as the B1 GUI application!

I agree however that there are cases where it would make sense to make that distinction, but - as mentioned - this is not available at this point in time + I don't think it will come in the near future.

What you could do however is:

Add e.g. an "Additional Authorization" on form no. 390 (= Journal Entry) and have the system administrator using that instead of the built-in Authorization for "Financials" -> "Journal Entry".

As a consequence the user may e.g. not be able to open the "Journal Entry" form, but you would still be able to add a Journal Entry through DI API...

What do you think?

[Former Member · Accepted solution]

That's a very clever idea. I will try to arrange to try this out here and let you know if it works.

[Former Member · Accepted solution]

Well, that would be a great solution, but I tried it and the user authorization that I created is preventing the DI from accessing the object! I tried creating a user authorization called "Business Partners" that is linked to form 134. Then when I try to use the BusinessPartners DI object from a user who has read-only access to Business Partners, it fails. I'm using 2004A -- maybe 2005A behavior is different?

[Former Member · Accepted solution]

Sorry, I should be more specific -- I have full control access for the built-in Business Partners authorization and Read-Only access for the user-defined authorization.

[former_member185703 · Accepted solution]

That's too bad (I have to admit that I didn't try it - or I don't recall the result when I did months ago).

In this case you will have to implement the behavior you want - just without support through "Additional Authorizations" - in your code...

Sorry, but I would not expect the behavior that bothers you to be changed in the near future, but I will check whether this question has been raised before + whather it is planned to do sth about it.

[Eneveux]

Benjamin,

The DI API relies on the Business One security and permissions infrastructure and this in turn also requires a valid named user license for a user to be able to access Business One through the API's. Permissions as to what a user has access to such as Sales Orders or Purchase Orders or Business Partners is controlled using the Business One Permissions functionality. If the user is a Named User with a Professional User license than that means they have access to all functions in Business One that permissions have been set for them to use. Other licenses types such as CRM-Sales, CRM-Service and Add-on user licenses actually restrict the functionality in Business One that a user with that license can see or use regardless of permissions. You have the ability to set permissions on user defined forms and objects using the UserPermissions object. If you are trying to specifically set permissions as to who can create Sales Orders for example, then this can be set for the user in Business One and the add-on through the DI API will have to follow that same permissioning. What you cannot doe is set the type of documents within Sales Orders that a user can or cannot enter. If the user has permissions to Sales Orders then they can enter any type of Sales Order.

Unless I am missing the point (and that is possible), I think that about covers it.

HTH,

Eddy

[Eneveux]

Benjamin,

If your question is that you do not want to have the user have to log into the application and have the system automatically log into Business One and create transactions as that user, then that is possible by embedding the user and password for Business One as well as the SQL Server in your code.

HTH,

Eddy

[Eneveux]

Benjamin,

Unfortunately in this case you cannot set permissions on specific documents as the API's follow the same permissions and security as the Business One application itself, ie. you get this for "free" and do not have to use code to develope your own security.

HTH,

Eddy

[Former Member]

But the Business One application itself can modify and read any data regardless of who's logged in. Is there an expected mechanism by which a DI-based application should do the same? Is it supposed to log in as manager? Is it supposed to circumvent the DI business objects completely? What if a DI-based application, for example, needs to look up a Business Partner's payment terms when creating a document on behalf of the currently logged-in user? Is there a proper way to do this?

[Former Member]

Another example: what if the DI-based application needs to create a goods receipt or an invoice on behalf of the user regardless of that user's security because the user performed some operation that needs to trigger this automatically. The admin may not want to allow the user to directly create these documents, but wants to allow the application to implicitly create them. (Perhaps Journal Entries would be a better example -- don't many kinds of operations implicitly need to create journal entries?)