Hi,

Im trying to set up an authorisation system in LN. I want to restrict all users to work only on records of table tcmcs029 wherever the business partner type is "123" . Ive created a role and and added the required authorisation thro'session ttams3145m000(Table Data Authorisations).The authorisation is working fine and only selected records are displayed of table tcmcs029; however i cant access any other table. System throws an error "No read authorisation for table tcibd001" whenever i open a session based on some other table. To access some other table exclusive auhoristaion has to be given for that table. Unlike in baan 4 where by default a full access is given to user and we retrict the access by implying conditions, in LN if i define the authorisation even for one table , i have to define full access authorisations for all other tables.
Im sure im missing some vital step here. Has any one ever worked on authorisations in LN?

Let me know if any further clarifications are required.

Bye

You have to define default company/all-company authorization in ttams3144m000 or specific package/company authorization in ttams3140m000.
It is behaving as expected, when you do not have any table data authorizations specified it means you have wide access, once you start restricting any table/company/package/module etc, you have to the default inclusive & exclusive authorizations.
Refer to the Tools Administrator's manual for more info on the Role based Authorization Management System (AMS).

Hi NP Rao,

I have already tried the step you suggested. If i grant authorisations at company or package level, the user gets a full access i.e. the restrictive authorisations defined at table data level are completely ignored. I have read the manual of AMS and i quote below the concerned material from hard copy of the manual (page 3-51)

" When there are many roles , there is a cumulative effect of the authorisations attached to these roles.
Multiple roles always add to the authorisations of the user. For e.g. if one role gives authorisation to perform a task and a second role also attached to that user , does not give that authorisation , then the user still gets the authorisation.
If a single role states that the user has permission for a session and another role states that the user has no permission for that same session, the user will ultimately have permission for that session."

For a single riole , i have inserted a table data authoristaion(ttams3145m000) restricting the access, and for same role i have given a full authorisation at company level(ttams3144m000). Like the document said , ultimatley the user has full access thus defeating the very purpose of authorisation.

Awaiting your inputs/feedback on the same.

Bye

I am not sure if you are referring to the latest Tools Adminstrative manual, then its Chapter 7 - User Management. You have to refer to the Sections 7.1, 7.2
" When there are many roles , there is a cumulative effect of the authorisations attached to these roles.
Multiple roles always add to the authorisations of the user. For e.g. if one role gives authorisation to perform a task and a second role also attached to that user , does not give that authorisation , then the user still gets the authorisation.
If a single role states that the user has permission for a session and another role states that the user has no permission for that same session, the user will ultimately have permission for that session."
Yes the statement is a little confusing, but it is applicable only for Session level authorizations.
You have to design based on the table level authorization priority execution logic-
The database authorization priorities in Table 7.2 show that the database
authorization with the highest priority (1) is stated at the most specific level and the lowest priority (14) are stated at the most global level. The database
authorizations that you define for a specific company have a higher priority than those defined for all companies.
Table 7.2 Database table authorization priorities
One company All companies
Database table field data authorization 1 2
Database table field authorization 3 4
Database table authorization per table data 5 6
Database table authorization per table 7 8
Database table authorization per module 9 10
Database table authorization per package 11 12
Database table authorization per company 13 14
I used this setup and we have very few roles which use the table & company level restrictions and they are working. I cannot be of much help, when I can't see your role settings.

Hi NP Rao,

Thanks for your reply. Kindly find attached the document for the steps that im following to set up the authorisations. Im referring to the hard copy of the manuals which SSA sends. It is titled as "Enterprise Server Administration Volume 1" and has datestamp of 03/3005. If possible kindly send me a softcopy of the document that you are referring to (but how do i make my server to read your manual LOL )

Awaiting your guidance on the same.

Bye

Try to set the restriction not for all companies but for a specific company.

HI,

Tried setting up authorisations for specific company, but the system behaviour is unchanged. The priority of authorisations is exactly opposite from what NP Rao has written in his earlier post i.e. from global level(top priority) to specific level(least priority).

Bye

I looked at my definitions and i took the other way. I gave the user full access for the hole company and denied the authority for records with field value not equal "123" (like your example).

I think it's a bug - I experienced the same in a project: If eg you have set full table authorizations for package tc and put a no access restriction on table tccom001 for a range of particular values in the emno field, those field level restrictions are not considered by the system - you still have full access. If that's the case, it's best to file a case with the Infor support.

I tested it today, refer to the attached document.

If possible kindly send me a softcopy of the document that you are referring to
If you do not have the latest documentation, contact you local BaaN Support or download the documents from the BaaN Support Site.

Be aware -
© Copyright 2005 by Baan International B.V., a subsidiary of SSA Global Technologies, Inc.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any way or by any means, including, without limitation, photocopying or recording, without the prior written consent of BaanTM International B.V.
Important Notices
The material contained in this publication (including any supplementary information) constitutes and contains confidential and proprietary information of Baan International B.V. By gaining access to the attached, you acknowledge and agree that the material (including any modification, translation or adaptation of the material) and all copyright, trade secrets and all other right, title and interest therein, are the sole property of Baan International and that you shall not gain right, title or interest in the material (including any modification, translation or adaptation of the material) by virtue of your review thereof other than the non-exclusive right to use the material solely in connection with and the furtherance of your license and use of software made available to your company from Baan International pursuant to a separate agreement (“Purpose”).
In addition, by accessing the enclosed material, you acknowledge and agree that you are required to maintain such material in strict confidence and that your use of such material is limited to the Purpose described above.
Although Baan International has taken due care to ensure that the material included in this publication is accurate and complete, Baan International cannot warrant that the information contained in this publication is complete, does not contain typographical or other errors, or will meet your specific requirements. As such, Baan International does not assume and hereby disclaims all liability, consequential or otherwise, for any loss or damage to any person or entity which is caused by or relates to errors or omissions in this publication (including any supplementary information), whether such errors or omissions result from negligence, accident or any other cause. Baan International B.V., is a wholly owned subsidiary of SSA® Global TechnologiesTM, Inc.

Hi NP Rao,

Thanks for your reply.Finally i got it working for me based on your feedback. I used the "not authorised" setting instead of "delete/insert/modify/read" option and authorisations are working as they should.
In general I would summarise the authorisation process as ,

1. Grant all authorisations at global level (company /package/module) and use "not authorised" at specific level to filter OUT the records.

OR

2. Restrict the access at global level and use "delete/insert/modify/read" to filter IN the records.

I was granting access at global level but was using "delete/insert/modify/read" option at specific level assuming that LN will automatically remove these authorisations whenever the condition was not satisfied.

Thanks all for your valuable inputs.

Cya

t is possible to obtain a manual to create new authorization lists

You should contact infor for the latest documentation. That is the correct place to get what is needed for your specific system.