Posts

Chrome 80 Browser SameSite Workaround

With the Chrome 80 update, here is a simple workaround to disable SameSite cookies.

 

To get started open your Chrome Browser.

Type chrome://flags in the URL and press enter:

Search cookies and set SameSite by default cookies and Cookies without SameSite must be secure to disable, then relaunch the browser:

Confirm changes after relaunching and that it!

 

Watch the accompanying video below for a visual guide.

How to dump RQ02 approval strings out of a Lawson database

Lawson RQ02 approval strings work hand in hand with Landmark and are setup in different ways per organization. Some use general hierarchal titles and some use individual usernames. Regardless of how you implement it, you want to be able to create a report so you can update them as individuals join/leave/move around the organization

To generate a database dump of all approval strings and their levels using my method, you’ll need read access rights to the LSL database and must be using SQL.

  1. Login to your TEST or PROD database application.
  2. Create a new query window and paste the below SQL code in, one is a screenshot to show syntax highlights and the other is the raw code for your convenience.

  3. Run the query, copy and paste with headers into Excel to filter down the data or edit the query.

I’ve renamed various column names to reflect the different levels and dollar amounts more clearly. Feel free to change the query to your liking. This is only the RQ02 strings, to get the filters for users’ setup in Landmark, check out my article titled: “Generating a simple approval level report from the Landmark database”.

How to Restrict a Specific Form Table Field in Lawson Portal

For this tutorial, we will be restricting a table in CU01.1

  1. Login into Lawson Security Administrator
  2. Load up your default security profile typically titled PROD10 or TEST10
  3. Add a new security class

    Ours will be called TestSecClass
  4. Grant token access to CU01.1
  5. Once this is added, we want to restrict a specific table on CU01.1 to find the table name, go to CU01.1 and press CTRL + SHIFT + O when selecting the field
  6. Back in LSA, set CUC-CURRENCY-CODE to Deny Any Access
  7. Add this new class to a role of your choice. Add the role to a user and test CU01.1. To learn more about how Lawson security handles access, check out my other article titled: “Lawson Security – The Theory of Least Privilege Access Explained”

Creating an LBI Dashboard Series – Adding a Module (Part 2)

To start at the beginning, check out Part 1 of this series titled: “Creating an LBI Dashboard Series – Getting Started (Part 1)

 

For this part in the series, we will be adding a simple module to our new LBI Dashboard.

  1. First login into LBI environment as an admin user.
  2. Go to your newly created dashboard
  3. Click the + icon on the top left and select “New Module”
  4. On the Main tab, title your module, ours will be called “Payroll”
  5. By Default, the module will inherit access from the Dashboard itself, if you want to further restrict each module to separate users, you would do this again here. The expanded checkbox is great for convenience as the Module will be expanded by default:
  6. Go to Appearance Tab and select a Icon for your module to help distinguish it from others, we will select the money icon for Payroll module:

  7. When done select Save and you should see a blank Module in your dashboard:
  8. To add reports to this module, click the gear wheel icon in the top right of the module and select Add Items and then Search. You can also select a direct URL but this is much easier.
  9. A Searchbox should come up, this is to search all existing LBI reports. Type in the report name you want, check “Search Reporting Services Reports” and click the search icon to see the results.
  10. Once you find your report, select it and click Save:

You’ve created a report module in your dashboard and added your first report!

That’s all for this article, keep an eye out for more in our LBI Dashboard series.

 

Creating an LBI Dashboard Series – Getting Started (Part 1)

LBI dashboards are useful for delegating reports to specific access and is essentially a frontend for all your user reporting needs.

For this part in the series, we will be going over the very basics and how to create a dashboard tab for Finance users and setup access so those users can access the dashboard.

  1. First login into LBI environment as an admin user.
  2. In the top right next to your admins username, you’ll see a gear wheel, click that and select “New Dashboard Tab”
  3. Enter a dashboard title and click OK, ours will be named Finance
  4. You should be redirected to a blank Dasboard, on your new dashboard, click the + sign in the top left and select “EDIT” (note you can select ‘Set Access’ but it’s simpler to go to edit)

  5. A new menu should pop-up with multiple tabs. Go to Sharing and select Edit Viewers for specific access
  6. In this screen you should see a set of users and groups (roles). In LSA, if users have specific groups assigned to their users, adding here will give them access to this dashboard. For our example we will be adding LBI-Payroll group from Lawson:
  7. All users with LBI-Payroll group will now have access to this dashboard. Press okay and Save:

This is the first step in setting up an LBI dashboard for specific users. Please note that LBI comes with a default role that all users must have which is typically called something like LBIUSER. Example below for this article:

A Brief Overview into the Lawson Requisition and Approval Process

Lawson allows for requester users to submit requisition orders for their organization. To make sure the orders are valid, Lawson also supports approvers to verify and approve/reject the orders.

The core of this is done by setting up Requisition Locations (RQ01) and Requisition Strings (RQ02) and having a workflow process everything in between.

Requisition Strings can be used in many different ways, but in our example it is to have individual approvers approve for a particular location. This can also be general titles like Manager, VP, etc. or however your organization wants to set it up.

As you can see below, these are strings for Company 100, Requesting Location RQ210 with Approvers starting at Level4 and stopping at Level6. The lower limit on the left is the amount that the users approve orders for and depending on the IPA flow logic, could notify or skip them.

When users track requsitions in say RQ10 for example, they can drill around and see history log via the strings themselves:

This is only half the setup for this particular organization.

 

Approvers have to be setup on the Landmark side via Rich Client or Process Server Administrator web application. This is done via “Filters” and these have to be named accordingly to what your IPA Requisition flow will coincide with.

Below is an example of how we would mirror the RQ02 strings in Rich Client (custom report).

The Level 4, 5, and 6 are the “auth id” that our custom flow matches up on. It then grabs the user from Landmark and send notifications based on where the requisition is in the flow.

Some organizations simply don’t use RQ02 strings as they may find it easier to process everything on the Landmark side.  Landmark does have a set of its own reporting tools and filters (See my other article titled “Generating a simple approval level report from the Landmark database“ for a custom database report I created).

The benefits of RQ02 strings in my experience is that the frontend functional users could setup the strings for the developers to mirror in the back end (or by an automated process if done right).

 

Hope this was helpful in giving you a brief overview of requisitions and approvers.

Generating a simple approval level report from the Landmark database

Lawson natively supports requisitions and a hierarchy requisition approval system within organizations. Some use both the approval strings found in RQ02 and setup filters within Lawson Rich Client (An application in Lawson Landmark). More info on this can be found in another one of our articles titled: “A Brief Overview into the Lawson Requisition and Approval Process”

 

To generate a database dump of all approvers and their levels using my method, you’ll need read access rights to the LSL, IPA, and GEN databases and must be using SQL.

 

    1. Login to your TEST or PROD database application.
    2. Create a new query window and paste the below SQL code in, one is a screenshot to show syntax highlights and the other is the raw code for your convenience.


      Run the query and your results should show as so:
    3. Copy and paste with headers into Excel to filter down the data or edit the query.

I’ve included an Active Status to show which locations are active or inactive. This can be changed in RQ01 per company and location.

Feel free to optimize the query to your likings if you see any inefficiencies. Remember, this is only for approval levels on the landmark side, not the RQ02 strings themselves.

Lawson Security – The Theory of Greatest Privilege Access Explained

When Lawson left LAUA security, it redesigned its hierarchical security as so:

  • Roles
    • Classes
      • Tokens (or rules)

These all followed the theory of the greatest privilege access since v9

 

What does this mean?

In the simplest form, it means that if there is an ALL_ACCESS and a DENY_ACCESS rule within the same class or role, the ALL_ACCESS wins and grants access to the rule.

 

Real world example:

Problem: Say you wanted to grant a user access to view an AP form but noticed that the form itself shows a vendor’s number under the TAX ID field.

 

If the vendor does not have a vendor number, typically they use their social security number and this is added to the TAX ID field which is a field on the APVENMAST table.

 

If we set DENY_ACCESS on the TAX ID field within APVENMAST as shown below:

When the user loads the AP form up again, that field will appear blank or greyed out.

 

Let’s say this user eventually takes on newer tasks and gets a new role assigned to them to submit requisition orders and this newly assigned access inadvertently grants ALL_ACCESS to the APVENMAST table.

This new access now overrides the DENY_ACCESS set on the TAX ID field and the user can now once again see the TAX ID field and reveal sensitive information such as a vendor’s social security number.

 

I hope this helps when designing your security for employees.

How to Analyze a Cloud-based Log Quickly in Lawson

In a Lawson Cloud environment, its difficult to get logs off the server since now you’re likely restricted to FTP access and the latest logs are currently being written to by the server itself, thus throwing a deny exception when trying to download the latest logs from FTP.

I previously made another article on this explaining a work around for this but that takes a few extra steps and time. This is a quicker command line method if you need to test something immediately.

 

  1. First login to Lawson Interface Desktop
  2. Go to the directory in which the logs exist
  3. Type this command: tail -500 <name of log file being written to> | lashow
  4. Example: tail -500 ios.log | lashow

As you see above, this uses the tail command combined with -500 parameter which returns the last 500 lines written to the log. You can change -500 to whatever amount of lines you want to return (the more the longer it takes to load)

The optional piped LASHOW command is to open this in a separate scrollable and searchable window within LID.

This becomes especially useful when testing live forms or code in Lawson.

 

Good luck!

Resolving the “Operator Not Authorized to Change Unit Cost” error

This is one of those Lawson errors that could waste a morning of work looking through the Infor knowledge base, analyzing/changing security, and or reviewing logs.

 

So, you’re on PO20.1 and want to make a change to a PO entry and get this error:

To resolve this is actually incredibly simple and can be changed on PO04.1 at the bottom of the Buyer Information Tab (your settings may be different based on your needs):

If you happen to get a similar issue for a requisition cost change “Requester not authorized to change unit cost”, simply go to RQ04 and allow unit cost override for the specific requester (your settings may be different based on your needs):