Navigation
Introduction
Only page, css and js types can be accessed with the url.
Regular implementation url’s in the editor would look like this
{instance}/{clientCode}/en/editor/my-products-page
This would be accessible from
{instance}/{clientCode}/en/my-products-page
Note that -page
suffix is not required and a link without it would still be routing to the correct location
{instance}/{clientCode}/en/my-products
Public / B2B
If the public features are used then the endpoint would prefix it with public
{instance}/public/{clientCode}/en/my-products
Sub paths for navigation
We can use the sub paths for navigation inside the templates.
Usually 3 extra sub paths can be used. We can access the path values with an indexed value from the path.
https://template-engine-eu10.erply.com/104706/en/test-food-ordering-choose-table-page/test1/test2/test3
We can then access the values using
{{ .Data.Parameters.path1 }} // test1
{{ .Data.Parameters.path2 }} // test2
{{ .Data.Parameters.path3 }} // test3
Goerp has a special parameter that can be used to get the last path parameter as well (all content after the last non-encoded /)
https://template-engine-eu10.erply.com/public/104146/et/some-page/test1/test2/test3/test4%2Ftest5
{{ .Data.Parameters.pathx }} // test4%2Ftest5
These routes will always navigate to the parent page, but
we can set up special rules in the page to make some changes based on the path parameters.
{{ if eq .Data.Parameters.path1 "test1" }}
{{ template "my-route-a-partial" . }}
{{ else if eq .Data.Parameters.path1 "test2" }}
{{ template "my-route-b-partial" . }}
{{ else }}
{{ template "my-default-partial" . }}
{{ end }}
We can use the tools helper to make navigating sub paths easier
{{ if .Tools.IsPath "my-route-a" }}
{{ template "my-route-a-partial" . }}
{{ else .Tools.IsPath "my-route-a/my-route-b" }}
{{ template "my-route-b-partial" . }}
{{ else .Tools.IsPath "my-route-a/my-route-b/my-route-c" }}
{{ template "my-route-c-partial" . }}
{{ else }}
{{ template "my-default-partial" . }}
{{ end }}
Subsections of Navigation
Sitemap
To produce a sitemap we can use the combination of multiple features
- The .xml document type suffix
- Application url configurations
- Automat api helper to produce us a list of possible pages
Create the file
Create a new page type and make it publicly accessible.
Under url configuration lets fill a static preset for the automat api for the application we want to produce
the list for.
Name: AutomatApi.Api.Get.myRequest1
Value: v1/application-sitemap/{My_app_uuid_here}
Also add the name and value pair to the request whitelist.
Add the following content to the page
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
{{ $records := .Data.AutomatApi.Api.Requests.myRequest1.Response.Get "records" }}
{{ range $records.Array }}
<url>
<loc>{{ .Get "loc" }}</loc>
<lastmod>{{ .Get "lastMod" }}</lastmod>
</url>
{{ end }}
</urlset>
This will produce the sitemap file for us when accessing it from the approriate endpoint with the correct
document type suffix.
{instance}/{clientCode}/en/editor/my-sitemap.xml
You can also manually produce and edit as you like.
Mapping sub paths
If some pages are using the sub paths features then we can use the url configuration sub paths area to map them. This
will make the automat api return all mapped sub paths to the sitemap.
We can use the hide checkbox there to make the page not be generated into the sitemap aswell.
Robots
We can use the txt type renderer to output the robots.txt file.
Note that this is only useful for instances that implement a custom domain, as the robots file
needs to be at the root of the page.

A basic robots file would have the following content and would be called using the .txt document type suffix.
{my-custom-domain}/robots.txt
ser-agent: Googlebot
Disallow: /nogooglebot/
User-agent: *
Allow: /
Sitemap: http://{my-instance}/public/104146/en/sitemap.xml
GoERP UI library contains a standard component named “Unified menu”. Applications must use this component
for navigation within the app.
The menu bar can appear at the top of the page — or the left side of the screen.
Menu position can be set in HTML by toggling a class name:
class="menu--topnav"
vs
class="menu--sidebar"
The position should be set according to user preference, so that when the
user navigates from app
to app, the menu always appears in the same position.
Read the preference from a CAFA setting, using the call GET /configuration
. Parameters:
application=GOERP
name=goerp-menu-position
level=User
level_id=<current user ID>
NB! Set the following header to the request:
If there is no preference set for this particular user, CAFA will return the accountwide setting
as the fallback.
Possible values:
If the setting does not exist or the value is empty, assume side
as the default.
(If you want to create a settings page where the user can change the preference, use the same
“application” and “name” to update the setting in CAFA.)
When integrating the component, make sure that the following elements display information
appropriate to your app:
- App name
- App icon
- Version number
- Link to app store (the “Upgrade” button)
Standard elements
The component also contains several standard navigation elements, to let the user navigate
between apps, tell them where they are right now and give them a
set of base features on every screen:
- Account number
- Company name
- Username
- Language switcher
- Account switcher
- Link to dashboard: “Switch application”
- Logout link
- Wiki link
Dashboard
On new accounts, the whole “back office” is meant to be a collection of GoERP apps.
The user logs in and arrives at a dashboard that presents these apps as a grid of icons.
Clicking an icon launches the respective app (and installs it if needed).
To switch to another application, the user needs to return to the dashboard.
Therefore, apps must have a “Home” icon or a link labeled as “Switch application” that would let
them navigate back.
Dashboard URL
GoERP has a special URL for representing the dashboard; navigating to this URL
auto-forwards the user to an actual dashboard page.
The special URL is:
/{clientCode}/{isoLanguageCode}/go-to-landing
Example:
By default, it redirects to
/{clientCode}/{isoLanguageCode}/start-main
“start-main” is a page from the GoERP app “Start page”. This app gets autoinstalled when needed.
Configuring the URL
The default can be overridden with a CAFA setting:
application: "GOERP"
name: "goerp-redirect-landing-url"
Both level=Company
and level=User
CAFA settings are respected; therefore
it is possible to create
this config as either a user preference (level=User, level_id=<user's ID>
)
or an accountwide setting (level=Company
).
The value of the CAFA setting must be a string. The following placeholders are supported:
{GOERP_URL}
- GoERP server root URL (for example https://template-engine-example.erply.com/)
{ERPLY_BO_URL}
- Back office root URL (for example https://example.erply.com)
{CLIENTCODE}
- Account number
{ISO_LANG}
- Current language, two-letter ISO code (for example en
)
{LEGACY_LANG}
- Current language, three-letter code (for example eng
)
Sample value (GoERP):
{GOERP_URL}/{CLIENTCODE}/{ISO_LANG}/some-page
Resolves to:
https://template-engine-example.erply.com/12345/en/some-page
Sample value (back office):
{ERPLY_BO_URL}/{CLIENTCODE}?lang={LEGACY_LANG}
Resolves to:
https://example.erply.com/12345?lang=eng
Linking to back office
Back office URLs have a predictable structure. Here is a sample URL (a product card):
https://example.erply.com/12345/?lang=eng§ion=product&edit=23
- The base URL (
https://example.erply.com/12345/
) is available as variable {{ .Session.User.BOLoginUrl }}
.
- Parameter
lang
is the current language. Use {{ .Session.Language.LegacyCode }}
. Please always set this parameter; if the user has switched to a particular language, they want this language to be remembered as they navigate through the system.
- Parameter
section
identifies the page: the form or the list view.
- Parameter
edit
is used on forms and indicates the ID of the record. If you want to open a new empty form, use edit=new
.
On an empty form, any field can be prefilled with a URL parameter. Use the form field’s name
attribute
as the URL parameter name.
The following URL opens a new invoice form. (For clarity, it has been split into multiple lines.)
- The document’s type will be set to “Receipt” (ID = 2),
- customer ID will be set to 99
- and warehouse ID to 2.
{{ .Session.User.BOLoginUrl }}
?lang={{ .Session.Language.LegacyCode }}
§ion=invoice
&edit=new
&invoice_type_id=2
&invoice_orgper_idDat_client=99
&invoice_warehouse_id=2
This approach only works for an empty form, not for saved records.
Prefilling back office list filters
Use this approach if a GoERP page must link to a legacy back office list view.
Erply back office list views use method="post"
forms, so filter presets need to be supplied
as POST parameters.
For example, opening the invoices page with the
“Creator” filter applied (invoices created by employee with ID 123) requires submitting a form:
<form method="post" action="{{ .Session.User.BOLoginUrl }}?lang={{ .Session.Language.LegacyCode }}§ion=invoices">
<input type="hidden" name="search_orgper_idDat_author" value="123">
</form>
Replacing back office pages
Back office forms can be configured to redirect to other URLs.
If a customer installs an app that manages products, they can make a product card always open in that app.
(And likewise, employee forms can open in an employee app, and customer cards in a CRM app).
At the moment this is a manual CAFA configuration step that must be done individually on each account.
- Go to Settings > Configuration Admin > App configuration.
- Click “Add new configuration” to create a new setting.
- Fill in the form as follows:
Field |
Value |
Application |
bo_ui |
Level |
Company |
Level ID |
leave empty |
Type |
ui_replacements |
Name |
Use any value, for example the name of the app that is going to handle the redirects |
Value Type |
JSON |
Value |
Define a JSON object as instructed below. |
Example (shown with all possible supported adjustments, all components optional):
{
"redirect_creation_form": [
{
"section": "prodin",
"url": "https://example.com/{CLIENT_CODE}/new-inventory-registration-page"
}
],
"redirect_edit_form": [
{
"section": "product",
"url": "{GOERP_URL}/{CLIENT_CODE}/{ISO_LANGUAGE}/edit-product-page?productID={RECORD_ID}"
}
],
"redirect_page": [
{
"section": "products",
"url": "https://example.com/{CLIENT_CODE}/product-list"
}
],
"add_tabs": [
{
"section": "orgperC",
"name": "metadata",
"title": {
"en": "Metadata",
"fr": "Métadonnées"
},
"url": "{GOERP_URL}/{CLIENT_CODE}/{ISO_LANGUAGE}/customer-metadata-page?customerID={RECORD_ID}"
}
],
"replace_tabs": [
{
"section": "orgperC",
"name": "contracts_new",
"title": {
"en": "A better tab for customer contracts"
},
"url": "{GOERP_URL}/{CLIENT_CODE}/{ISO_LANGUAGE}/customer-contracts-page?customerID={RECORD_ID}",
"replace": "orgperC_contracts"
}
]
}
Erply section name can be found from the URL: it’s the keyword following “§ion=…” Product card is product
,
inventory registration form is prodin
, employee form is orgperB
and so on.
The redirect URL supports placeholders:
{GOERP_URL}
- Base URL of Erply app store apps.
{CLIENT_CODE}
- Account number
{RECORD_ID}
- Record ID
{LANGUAGE}
- Three-letter language code (used in Erply back office)
{ISO_LANGUAGE}
- Two-letter language code (used in app store apps)
As many JSON objects can be created as needed.