Please enable JavaScript to view this site.

Navigation: Advanced topics > Programming topics > Security API > Methods

Security API: setAllowedPages

Scroll Prev Next More


Specify which pages the current user can access.


The setAllowedPages function should be called before the user opens the page it affects. Therefore, it is best suited for AfterTableInitialized/AfterAppInit and After successful Login events.


Security::setAllowedPages( $table, $pageType, $pages);


$table {string}

the table that the page belongs to.

Note: table names are case-sensitive and should be written exactly as they appear in PHPRunner. E.g., "dbo_Cars" can not be substituted with neither "Cars" nor "dbo_cars".


When calling this function from the AfterTableInitialized event, use the $table variable.

Use the GLOBAL_PAGES constant to manage common pages - the pages that don't belong to any table: menu, login, register, etc.

$pageType {string}

one of the page types. The available page types are: list, add, edit, view, print, report, rprint, chart, dashboard, login, menu, register.

Note: you can find the page type on the Page Designer screen in the page properties section:


$pages {array or string}

a page name or an array of page names the user should have access to.

Return value

No return value.


The setAllowedPages function does not affect the page types the user has no access to.


If, for example, access to Edit pages for the current user is prohibited on the Permissions page:



A call to setAllowedPages will not change anything. In this case, you can use this method together with the setPermissions function:


$rights = Security::getPermissions( "dbo_Orders" );
$rights["E"] = true;
Security::setPermissions( "dbo_Orders", $rights);
Security::setAllowedPages( "dbo_Orders", "edit", "edit1" );


On the other hand, setAllowedPages has priority over access rights to individual pages set on the Permissions page.


If, for example, the current user only has access to the edit page:



This code changes the page displayed to the user from edit to edit1:


Security::setAllowedPages( "dbo_Orders", "edit", "edit1" );

Example 1

Here are some basic examples of the setAllowedPages function.


After Table Initialized:


//allow access to the edit 1 page for the current user
Security::setAllowedPages( $table, "edit", "edit1" );


After App Initialized:


//allow access to edit and edit 1 pages for the current user
Security::setAllowedPages( "dbo_Cars", "edit", array( "edit", "edit1") );
//allow access to the menu1 page for the current user
Security::setAllowedPages( GLOBAL_PAGES, "menu", "menu1" );

Example 2

Show an alternative Welcome page, menu1,  to a user named mike.


After successful login event:


if( Security::getUserName() == "mike" ) {
Security::setAllowedPages( GLOBAL_PAGES, "menu", "menu1" );

Example 3

You can call this function in other events than AfterTableInitialized/AfterAppInit and After successful Login.


Let's say you want the current user to gain access to the edit1 page of the Cars table, use the following code before the user tries to access the Edit page:


// This code should not be put into the Cars - Edit page event
// Although Cars - List page events are fine
Security::setAllowedPages( "Cars", "edit", "edit1" );

See also:

Security API: getPermissions

Security API: setPermissions

Security API: getUserName

Security screen

User group permissions

Page Designer: Common pages

Table pages

Page Designer

About Security API


Created with Help+Manual 7 and styled with Premium Pack Version 3 © by EC Software