Separate the Home page and the Admin page

[ebruchez]

The term "Home" is a bit unclear. Candidates:

• Dashboard
• Admin Console

See also #1410, #1946.

[ebruchez]

+1 from customer

[ebruchez]

The idea is that the landing page, even if you have admin roles, should remain that. Then a separate page should have the admin functions.

As a first step, we can use home.xhtml in both cases and match it to two paths:

• /fr/
• /fr/admin: if the user has admin roles, allow admin functions

At a later point, the admin area can be expanded to other areas besides functions on deployed forms.

[ebruchez]

Consider:

• /fr/: show only latest version of form
• /fr/admin: show all versions

or have option to see/show latest/all versions, TBD.

+1 from customer

[ebruchez]

Updated suggestions:

• /fr/: landing page with tiles
  • Form Builder Summary (if access)
  • Form Builder New (if access) shortcut
  • Your Forms
  • Admin
• / and /home/: redirect to /fr/
• /fr/forms: same as old /fr/ but without admin functions
• /fr/admin: same as old /fr/ with admin functions if allowed, otherwise 403

Navigation options:

• buttons
  • would be consistent with navigation in Summary/Detail pages
  • but not consistent with how most sites/apps navigate
  • might still make sense for "Summary", as this is tied to the current form, and "Home" is configurable anyway
• navbar (preferred)
  • more consistent
  • could use a "9-dot icon" top right to go to /fr/ or to show a menu with the same tiles shown on /fr/
  • any configurability needed?
• Orbeon logo navigates to /fr/

[ebruchez]

• 503 on admin if no authorization
• on /fr/forms, don't show libraries, no matter the user's permissions
• backward compatibility of paths? redirect?
  • decided not to do
• link from / or new landing page

[ebruchez]

Now if I go to /fr/forms and nothing is defined in form-builder-permissions.xml, things are ok. But if I go to /fr/forms and I have for example this in form-builder-permissions.xml:

<role name="*" app="*" form="*"/>

then I see library forms as well. Should that be the case? This is because the /form API considers that the caller is an "admin" (having those permissions on all forms) and the logic of the API then returns all forms including libraries.

[avernet]

I don't think there is any point in the home page showing libraries, as those forms are not intended to be filled out. (Whether they should be shown on the admin page is more arguable.)

[ebruchez]

That's right, I don't think they should show on the Home page, which is meant to show the published forms only. On the Admin page, that should at least be an option if not the default.

One question is about the /form API, which right now changes behavior depending on the caller's roles. So even if you access /fr/forms, and if you have permissions to list all forms, then library forms are returned. That's a little funny but that's how things work right now.

[ebruchez]

The issue is in filterFormsAndAnnotateWithOperations() called by PersistenceProxyProcessor.

We should be able to call the API to specify separately whether we want the caller to honor the admin permission, derived from:

• incoming roles
• form-builder-permissions.xml

However, whether we show a form because it is accessible due to the permissions above doesn't mean we necessarily imply that we see library, unavailable, or forms without possible permissions.

If we want to keep backward compatibility, I think we need to add a URL parameter, for example ignore-admin-permissions=true.

[ebruchez]

For the backward compatibility of paths:

• before, reaching /fr/ would show the "home" or "admin" view depending on permissions
• now, we'd have:
  • /fr/forms to never show admin operations
  • /fr/admin to always show admin operations, or to be unauthorized if no access is possible
• also, we are introducing /fr/landing or maybe just /fr/ for a new landing page
  • Q: Are we ready to ship anything with 2022.1?

The question is, what should /fr/ do now? It seems that since we have/want a new landing page, /fr/ should be it or redirect to it. Possibilities:

• /fr/ is the new landing page, with a property to restore the old home/admin behavior
  • so we'd do an internal redirect?
• /fr/ client-side redirects to /fr/landing or other
  • redirection can be configurable to provide backward compatibility

One issue with redirects is with embedding, which doesn't support it. However, we typically don't embed the home/admin page. The Form Runner proxy portlet supports /fr/ (formRunnerHomePath), but the proxy portlet can be updated to support that.

[ebruchez]

Q: Do we need a backward compatibility mode for /fr/ or /fr/forms, which would work like before?

Also one reason to not client-side redirect is a question of backward compatibility if the app has been protected by path.

[ebruchez]

Confusion above between /home and /forms. Currently, /home/ shows our current (old) static landing page. But we had meant for the /fr/ paths to be:

• /fr/forms
• /fr/admin

Fixing some paths in the comments above to avoid the confusion.

[ebruchez]

This was done for Orbeon Forms 2022.1. Only missing thing is extensive doc.

• document

[ebruchez]

+1 for doc

[ebruchez]

Documented here and here