Programatically Open a UX by Name/Alias

[ChristopherG]

mikeallenbrown Cunning solution Mike, so instead of storing the component name, store the JS Action name that will open a specific popup? Am I correct in saying that Javascript actions only exist within the grid or ux context, in other words you cannot create global, app wide JA Actions without creating a pure JS version?

madtowng I am open to using any method that will achieve the objective but I will not be using any grid stored data, aside from a reference to a component to open or js action to call. Thank you for the sample code, it will take me a minute to wrap my head around it, but it may be a more robust solution if global JS Actions are not possible.

The reason we are chasing sql/grid based solutions is that we have access and distribution metadata we want to attach to the sql table report records. These settings are actually an intersection of hundreds of reports, across multiple apps, intersecting with multiple platform tenants and user roles. As a rule we have very little if any business logic contained in Alpha, all in SQL and we looking to hook our Alpha reports into the same architecture.

[ChristopherG]

I have to go off line for a while. Will attempt a solutions and post results later. Many thanks.

[mikeallenbrown]

mikeallenbrown Cunning solution Mike, so instead of storing the component name, store the JS Action name that will open a specific popup? Am I correct in saying that Javascript actions only exist within the grid or ux context, in other words you cannot create global, app wide JA Actions without creating a pure JS version?

Correct, store the action name. Javascript Actions only live in the component they are written in. That said a child UX can get a pointer to the parent object and then run the parent's JS actions (and vice versa). You could probably write a custom JS function to do a lot of this work. That may be a good option if you have a lot of grids/reports doing a similar process. Having to maintain it all would be easier if everything is in once place.

It may be beneficially to talk with a developer over the phone/zoom to help work out the details. It sounds like you have a lot of nuance to work through.

[ChristopherG]

SOLUTION 1:

I have built an example around mikeallenbrown 's simple and effective solution.

1. SQL Table holding a list of report names and a report codes.
2. The report code values are exactly the same as predefined Action JS scripts, each of which opens a different, report specific UX
3. Report table is presented in a grid or list, with a button on each row.
4. The grid or list buttons 'on-click' JS event, gets the "report_code" field value for the selected row, stores it in a variable and then uses the variable as a parameter in a call to run an Action JS of the same name.
5. The Action JS opens the UX for the corresponding report and a button on that UX will run the report with the requisite arguments.

This solution requires creating a report grid/list bound to the SQL table and having all Action JS calls predefined in the same grid/list component.

The advantages are:
- to be able to manage report access, scheduling and distribution as SQL objects and procedures, linked to the report_id
- to store report metadata (description, date added, date updated etc) linked to the report_id and to display as need on the client side

The disadvantage are:
- having to create an Action JS script and UX for each report, athough the UX was likely necessary anyway
- losing role based control over who can run a certain report at 'first control' level. You could still impose role control on the report specific UX "run report" button, but you could not, using using security roles, stop someone opening that UX. A work may be to create multiple report grids/lists each showing only a subset of report records and then to role limit who can open each grid/list.

USE [MYDB];
SET ANSI_NULLS ON;
SET QUOTED_IDENTIFIER ON;

CREATE TABLE [dbo].[reports] (
[rep_id] [int] IDENTITY (1,1) NOT NULL,
[rep_name] [nvarchar](50) NOT NULL,
[rep_code] [nvarchar](30) NULL,
PRIMARY KEY CLUSTERED
(
[rep_id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY];

--ensure the report name is unique
ALTER TABLE reports ADD CONSTRAINT uk_reports_repname
UNIQUE (rep_name);

--ensure report code is unique as it will be used as the name of the action js.
ALTER TABLE reports ADD CONSTRAINT uk_reports_repcode
UNIQUE (rep_code);

INSERT [dbo].[reports] ([rep_name], [rep_code]) VALUES
(N'Daily Production', N'rep_0001'),
(N'Weekly Production', N'rep_0002'),
(N'Monthly Production', N'rep_0003');
​

[madtowng]

I would think you could check role permissions before executing the javascript action.

[mikeallenbrown]

What madtowng said. You don't lose anything with this. I restrict access, based on security groups (roles), via Javascript. For example I have many system admin tools that regular users shouldn't see. To show/hide buttons (or other elements) I do the following:

onDialogInitialize Server-side function (UX of course)

dim pUser as p
dim sGroups as c = ""​

a5ws_logged_in_user_values(pUser)
sGroups = a5ws_get_user_assignments(pUser.userId)​

if is_one_of("System Admin",sGroups) then
   'Set a argument value
   e.arguments.set("ISSYSADMIN","True")
end if

UX JS function to show/hide

function isSysAdminUser(){
    var _arg = {dialog.object}.argumentValue('ISSYSADMIN');

    if(_arg == 'true'){
        return true;
    } else {
        return false;
    }
}​

Grid's don't have arguments (not like a UX anyways) but you can use a state variable in it's place.

[madtowng]

I would think you can be more proactive, considering you have the report information in a sql table, is there
anything preventing you from storing roles along with the report data ?

[ChristopherG]

Apologies for the tardy reply. Yes indeed the reason for managing reports out of the DB is to connect it to the rest of the ERP superstructure. It opens up all manner of intersections between reports and other general platform functions (security controlled access, distribution lists, aws storage) and module specific functions (eg. scheduled or triggered compilation based on module specific events). While there will always be an essential xbasic element to this, we always build from the perspective of one day adding other interfaces or even reporting engine. So the solution I posted above is simplified from my actual db implementation which uses field names that are more specific, eg "aa_report_code", so that we can add fields that reference other reporting tools as needed.

[madtowng]

I expect it will never happen as I'm about to suggest, but I think this will be a better scenario.
Presume you have a report named sensitivedata.
I would expect somewhere in your superstructure, you have (or could have), a code of some sort that indicates
a minimum security level to access the report.
When you do your query for reports, check the user's security level; if it fails to meet the report requirements, don't even return the report.

[ChristopherG]

No you're spot on. Our reports are grouped by module (eg Estate Management, HR etc) and access level and so when we open the reports list/grid for a specific module tui, the list/grid is filtered by both the module name and user access level.