Restrict Landing page view to site logged into

Does anyone know if there’s a way to customize a landing page so that it only shows results for the site that the user is logged into?

Discovered today that Cycle Period Definition shows all periods for all sites, which caused confusion where we thought the screen wasn’t behaving correctly/same as Classic when creating new periods.

The Site column can be unhidden and the Landing Page grid filtered to show the site user is logged into, but I would prefer that it defaulted/restricted to this, so it at least appears that you can only update/create new periods in the site logged into.

Or should I report this as a bug, since it does let you search for and edit periods created for different sites than you’re logged into, whereas the Classic version only ever gave you access to the logged into site?

Yeah let me get back to the office.

Try this, I can’t test it because we don’t use it.

//Pre-Processing on Erp.BO.CCPeriodDefn.GetRows

if(callContextClient.ClientType == "Kinetic" && callContextClient.ProcessId == "CCPeriodDefnForm")
{
    whereClauseCCPeriodDefn = $"Plant = '{callContextClient.CurrentPlant}'";    
}

If that doesn’t work, you can do a post processing on the rows with the same conditions.

//Post-Processing on Erp.BO.CCPeriodDefn.GetRows

if(callContextClient.ClientType == "Kinetic" && callContextClient.ProcessId == "CCPeriodDefnForm")
{
    List<CCPeriodDefnRow> rowsToRemove = result.CCPeriodDefn.Where(x => x.Plant != callContextClient.CurrentPlant).ToList();
    
    foreach(CCPeriodDefnRow row in rowsToRemove) result.CCPeriodDefn.Remove(row);
}
1 Like

First one worked, but basically killed using filters on the landing page grid. This post-processing one works better, but there has to be a grid filter of some sort entered before it will return results.

Appreciate you coming up with these possible solutions. We only have a few users who use this screen and I’ve warned them about paying attention to the site, so going to leave it at that for now; don’t bother trying to fix the filter issue on my behalf.

1 Like

Well if the first one works, just change the code so it adds the where clause instead of replacing it.

Then the filters should work.

Reaction Confused GIF

Not a coder. :confused:

1 Like

Someone else may can use it.

I’d have to see how the where clauses come in from the filters to be absolutely sure,
but this is probably it:
Edit: I looked to see. Wrap it in parenthesis and AND it on there.
The effect is just like adding a filter for Plant.

//Pre-Processing on Erp.BO.CCPeriodDefn.GetRows

if(callContextClient.ClientType == "Kinetic" && callContextClient.ProcessId == "CCPeriodDefnForm")
{
    whereClauseCCPeriodDefn += $" AND (Plant = '{callContextClient.CurrentPlant}')";    
}

I changed it from:
whereClauseCCPeriodDefn = $"Plant = '{callContextClient.CurrentPlant}'";
to
whereClauseCCPeriodDefn += $" AND (Plant = '{callContextClient.CurrentPlant}')";

The first is setting the where clause, the second is adding to it.

You could also do this with widgets, couldn’t you @JasonMcD :slight_smile:

1 Like

@klincecum I have not been so bold as to try to modify existing apps with a BPM. My world usually involves piggybacking on or creating processes. Or hating an exisitng app so much that I make a new one from scratch. Point is, I don’t know where you’d begin with that. Neat idea to append the where clause though.

To me, yes that’s certainly a bug. Support will disagree no doubt. But why not report it, at least to get clarification. (And share the response here, please.)

Will that even work, if you use a period intended for site B in a cycle for site A? I’ve obviously never tried. I mean, I guess a period is nothing but a block of days.

BPM validates fine, but when I open the CC Period Definition, I immediately get a “Sorry! Something went wrong.” error. When I close that, the grid loading circle turns forever and the grid is locked up with no results showing.

Response from Support:

We have been able to replicate the behavior you reported and have submitted it to our Development team for review under {PRB0265627}.

Our Development team has determined issue will resolve in Kinetic- 11.2.400.


Further information from the Problem, where it's happening in also Cycle Count Maintenance:

· PROBLEM DESCRIPTION: Kinetic UI and the Kinetic Browser incorrectly display counts in Count Cycle Maintenance from other Sites the user is not currently logged into.
· EXPECTED BEHAVIOR: In Count Cycle Maintenance the Kinetic UI and Kinetic Browser should only display counts in the site the user is currently logged into.
· WORKAROUND: NA
· ADDITIONAL INFORMATION: This works as expected from the Classic UI. Issue only occurs in Kinetic UI and the Kinetic Browser.
This can directly cause security problems where users would be able to start and process counts in other sites they are not supposed to or are even logged into.

11.2.400 apparently refers to 2023.2

1 Like

Yes because I’m occasionally (often?) a dumba**.

//Pre-Processing on Erp.BO.CCPeriodDefn.GetRows

if(callContextClient.ClientType == "Kinetic" && callContextClient.ProcessId == "CCPeriodDefnForm")
{
    if(!String.IsNullOrEmpty(whereClauseCCPeriodDefn))
    {
        whereClauseCCPeriodDefn += $" AND (Plant = '{callContextClient.CurrentPlant}')";    
    }
    else
    {
        whereClauseCCPeriodDefn = $"(Plant = '{callContextClient.CurrentPlant}')";    
    }
}

Wrote off the cuff because I’m not able to get to Epicor atm.

I can’t find any fault with this. Works great!