I'm trying to use the database authorizations sessions to restrict users from using a specific PO Type. When I set up the Table Data and Table Field Data Authorizations via the standard sessions the restrictions work (after create runtime on the user).

I have created a new script to mass update all users.

Table ttaad434 stops user from committing records where cotp = PE2. Table ttaad435 stops users at the time of entering
PE2 on the Order Type field.

Problem is, once I run my script the data is confirmed, create
runtime is done on the user, but the restrictions do not appear to work.

I'm logged into a DEM user using bsp as the login as opposed
to the specific user's login.

Does something else come into play when inserting ttaad434,
and ttaad435 records via standard logic - what am I missing ?

Thanks in advance.

BaanTech

Here is all the info, I gathered from BB and other sources/forums. I hope it helps everyone out here.

There is so-called "Tools authorization" and the "DEM authorization". In both you can define roles but they are completely seperated authorization mechanisms.
If you run through the Dynamic Menu Browser always DEM authorization is used. DEM authorization is defined completely in the tg package, by creating roles (tgbrg8110m000) and attaching them to business processes or activities. In the EME you can define the authorization the role has. Authorization cannot be defined on field level but only on session and "subsession" (sessions called from a session) level. DEM authorization completely overrides the Tools authorization.
If you run though the 'static' Menu Browser (ttdskmbrowser) Tools authorization is applied. This authorization is defined completely in the tools (tt) package. In the authorization tab of the User Data session the tools roles are defined. Within Tools you can define authorization on field level.

Using Worktop both authorization mechanisms (DEM and Tools) can be used simultanously. Both the Menu browser and DEM browser appear in one single User Interface, but if you run a session from the Menu Browser Tools authorization is applied and if you run it from the DEM browser DEM authorization is applied (and so Tools authorization is ignored).
-2- From this question it appears to me that you might mix up two different authorization mechanisms; there is so-called "Tools authorization" and the "DEM authorization". In both you can define roles but they are completely seperated authorization mechanisms.
If you run through the Dynamic Menu Browser always DEM authorization is used. DEM authorization is defined completely in the tg package, by creating roles (tgbrg8110m000) and attaching them to business processes or activities. In the EME you can define the authorization the role has. Authorization cannot be defined on field level but only on session and "subsession" (sessions called from a session) level. DEM authorization completely overrides the Tools authorization.
If you run though the 'static' Menu Browser (ttdskmbrowser) Tools authorization is applied. This authorization is defined completely in the tools (tt) package. In the authorization tab of the User Data session the tools roles are defined. Within Tools you can define authorization on field level.


Aren't the 2 authorisation scheme more like double layer authorisation?

The Tools authorisation defines at the "program level" what session, table, table field, and library can be accessed. This is the first/basic layer. If DEM's not used, then this is the only authorisation level available. There are 2 modes here, super user who gets everything and normal users for whom the authorisation to certain session, table, table field, and library must be explicitly defined. To ease authorisation definition for normal users, roles are provided to group users according to their access area (e.g. Distribution functionalities only, etc)

The DEM authorisation defines at the "DEM user interface level" of what can be accessed. This is the second layer, sitting on top of Tools authorisation. To ease authorisation definition for everyone in this UI level, roles are provided to group users according to their functional area (eg. Sales manager, buyer, production supervisor, etc.).

If a user get Tools role of Distribution functionalities only and he was given DEM role of Finance manager then he still wouldn't be able to work. This is because the basic layer (Tools layer) restricts him from accessing finance functionalities even though the 2nd layer allows him.

However, it is correct that the user doesn't have to be super user in first layer (Tools layer) in order to use DEM. The user can also be normal user but make sure that the person is given the adequate access at this level to what he needs. Otherwise, he wouldn't be able to access those things in the second layer


It depends on the Baan version you are using:

- Baan4:
On Baan 4 DEM you can only define either full authorization or no authorization. When the DEM menu is generated, it overrides the current autohorization defined in the Tools tables. And so if you did define no authorization in the Tools, specified full authorization in DEM, DEM will override the Tools authorization. So for Baan4 there is no double layer authorization; DEM rules.

- Grieg
Grieg (5.0b) is a "special case". Within DEM you only limit the authorization as specified in the Tools. So you define basic authorization in the Tools and using DEM you can only narrow the authorization. So in this case you are right, this is a 'double layer authorization'.

- Corelli, Verdi, Reger, later versions
In all these BaanERP versions (5.0a, 5.0c, 5.1a, 5.2a, 6.0 in the future) again DEM rules. So no matter what authorization you defined in the Tools, DEM will completely overwrite these authorizations. In fact, this is how it works; when you log in into the Baan system tools authorization is used. But right after starting the bshell, DEM takes over and disables AMS (Tools authorization mechanism).

Note that in all cases there is a third authorization mechanism; the database authorization. No matter if you use DEM or Tools authorization, the database authorization rules in the end...
So there is indeed a double layer authorization, but that applies to DEM vs database and Tools vs database, not for DEM vs Tools (not for other versions then Grieg that is).

However, keep in mind that DEM authorization and Tools authorization are defined seperately. DEM authorization is defined when attaching a DEM role to a business process or activity in the EME (Enterprise Model Editor, a seperate Windows application). Tools authorization is defined in the tools package.
And so field level authorization defined in Tools will not effect authorization of DEM users. DEM does not support field level authorization. However, you can use database authorization to permit DEM users to write to certain table fields.

A Baan user is always linked to a database user. The database user authorization always determines the maximum authorization. Using Tools or DEM you can only narrow the authorization but never gain more rights then the associated database user.

how to give database authorization to permit DEM user to write to certain table field

I'm trying to use the database authorizations sessions to restrict users from using a specific PO Type. When I set up the Table Data and Table Field Data Authorizations via the standard sessions the restrictions work (after create runtime on the user).

I have created a new script to mass update all users.

Table ttaad434 stops user from committing records where cotp = PE2. Table ttaad435 stops users at the time of entering
PE2 on the Order Type field.

Problem is, once I run my script the data is confirmed, create
runtime is done on the user, but the restrictions do not appear to work.

I'm logged into a DEM user using bsp as the login as opposed
to the specific user's login.

Does something else come into play when inserting ttaad434,
and ttaad435 records via standard logic - what am I missing ?

Thanks in advance.

BaanTech


Hi I also want to do the same thing. e.g I want to restrict the user to access/visibility of certain PO.

How to achive this