I'm working with Wappler and learning from Projects Hq. I came across a pattern related to authentication and role-based rendering that I’d like to better understand.
In multiple .ejs files, there are conditional blocks like this:
These blocks are rendered only when the logged-in user has admin in the role field.
While exploring the backend, I found the current_user action inside Workflows/API/Path(auth). It seems to be responsible for providing the authenticated user data used in these conditions.
However, I couldn't find any explicit Server Connect call in the pages that invokes this API.
This made me wonder how and when this data becomes available to the .ejs templates.
Question:
How does Wappler make authenticated user data (like role) available in EJS templates without an explicit API call, and when is the current_user action actually executed?
What you explained was clear, but due to my inexperience I didn't understand. Since I'm using the example HQ project to make it easier for me to understand, at what point does it execute the 'current_user' action?
Hi George. Im sorry if I seem reluctant to use tours, but I'm not fluent in English, so everything becomes difficult to understand when using tours...That's why I try to get my questions answered here, since the browser translates and even then it's not easy. If it's difficult for you to answer here, I understand.
I looked through the (http://docs.wappler.io) tour and didn't find it.....If someone manages to understand my doubt and can answer me, I am immensely grateful.
The code runs on the server every time the page is rendered in response to a request.
Explanation
<% if (user is Admin) { %>
... admin‑only stuff ...
<% } %>
What <% … %> means
These tags tell the server: “Execute this logic while generating the page; do not output it as HTML.”
<% … %> = run code, output nothing
<%= … %> = run code and output the result
When it runs
This block is evaluated on the server for every request that renders that page.
If the user is an admin, the server includes the admin‑only markup in the final HTML.
If not, that markup is never sent to the browser.
Why this matters
Because this logic runs inside the server‑side templating engine, it completely bypasses Wappler’s API / Server Connect system.
That means:
No API action is triggered
No client‑side App Connect logic is involved
The decision happens before the browser receives anything
Non‑admin users never see the admin HTML at all, not even hidden in the source
This is fundamentally different from using App Connect conditions, which only hide or show elements after the page has already reached the browser.
This is server‑side templating, so the check happens before any App Connect or API logic runs. It’s not an API action, it’s part of the page rendering pipeline.
