Bringing some of our chat onto this thread in case others are interested.

Generally when I am granting Power users API rights to perform an activity I follow one of a few processes but in this case would be:

1. Create a custom page they can access.
2. Embed a qualtrics survey (or an application you can control and has abilities to trigger API calls) onto the page as the front end of the application. The survey in this case I would have identify the user automatically, autoselect their pages available to them to let them choose what they wish to update, and then a body box for them to enter their updates.
3. I’d probably do some type of scheduler on it, do you want to publish immediately, this evening, or select a date, the data in this case would be stored in a central spot and then have a process run each night to see what updates to perform.
4. Could have a small preview prior to submit that gives a rough idea of what they are submitting just widget wise, not full page, allowing them to go back and tweak if wanted.

Now, a large pain point here is translating the content from the WYSIWYG editor of form entry into valid html and then into encoded html for the API call. Doable, but there are a lot of potential gotchas in that process. Need to be very careful.

Actually sounds like a fun little applet to build out. 

My path here I think will be KISS

They get to edit ONE html widget on ONE page. All the rest of the page is standardized. Build out from there.
 

We use Auth0/Okta so controlling access should be easy enough. 

Can you embed a qualtrics/jotform/etc directly in Docebo html widgets? Or only via iframe (not mobile app compatible)

Proof of concept worked as Bfarkas and I discussed in DM. Api can overwrite page content and alter the contents of an html widget. It works via API Explorer. 

So there is a trick where you embed the form into an iframe widget on purpose so that you can then use the advanced setting to turn oauth on, which adds valuable information into the direct URL of the form (logged in user’s docebo id for example), which the form can then ingest and know who the person is without asking or setting up any other login. This is the type of thing I would suggest is not able to be done via mobile app as well, I get consumption but the editing will get real sloppy that route, so ruling the app out for a power user to do an update activitiy doesn’t seem unreasonable to me.

Interesting - but in our case we know their docebo ID anyway if they’re on desktop - because they’re logged in via Auth0/Okta. Still, that’s another cool idea to explore - how does that work exactly (oauth via widget)? I do know how to salt-secret but this sounds different.

The form needs to know it, so it can pass the info onto whatever process being used to calculate (plus you can make fields on the form auto-calc based on the ID, for instance auto-selecting the page they use) if that is getting passed over, excellent, most of the time I’m working with folks they don’t have that luxury, additionally the embed option lets the form perform API calls directly if your form platform supports it  using a properly authenticated setup the user needs to know nothing to leverage.

Basically, you create an oauth app in Docebo, then select it in the iframe widget advanced settings:
 

On page load, it will add a bunch of variables to the iframe embed url:
 

Gives you: user ID, auth code (can be exchanged for a valid oauth 2 token to use with API calls), and if on a course page will give you the course ID and code they are on. 
 

I have a full writeup of this coming in the 7th installment of the API series.

Holy guac fellas. Thank you for the write up. A remarkable approach.

I will share details as I continue - maybe this could be a community open source app once I’m done making it (under the assumption others who use it will help improve it if able)

@Bfarkas how do I get the salt secret?

You have to build a oauth app in the admin area:

I was curious on this on Friday so built a fast working prototype using my form embedded setup descirbed above, uses a qualtrics form as the front end, embeded in a custom page for interaction, based on the logged in user they get a selection list of pages and widgets per page they can edit, then it is basically just a wysiwyg editor on a large text field.

I did go ahead and add a date selection field for publication with the default being immediately (if they pick a different day it happens at midnight eastern time), and the data is just stored in a SharePoint site that is checked each day at midnight for any updates that need to be run which trigger the power automate flow to update.

I just need a better way to manage who has access to each page, right now managing via a different sharepoint list that feeds into the qualtrics API to set re-usable field choices for the form, but a bit too manual for my liking, noodling on a  diff solve there.

Progress update - and yes that is the actual content of page 31 in Docebo

Nice, you’re getting there!

You’re doing this one page to edit form?

Hm?

Right now just editing page 31

Eventually, superadmins will be able to enter usernames (emails) and page numbers those users can edit

Then, when those users access this page, they’ll get a list of pages they can edit.

This isn’t a form it’s a webapp - eventually it’ll display the rows and columns for any full pages on docebo, and allow edits to html and image widgets (Tbd on widgets)

Understood, I do the same on my form, don't think of it as a form, its just a pre-built webapp instead of needing to build the backend myself (I’m lazy and don’t like recreating if I don’t need to)….where are they entering the info for the known users? I have that happening in a SharePoint list as a lookup table that the form uses to just identify you’re user X you get these 5 items in the dropdown, which lets anyone at the org regardless of Docebo rights control it. 

I enter it - or enable other admins. Directly in the panel then it is encrypted and stored.

Nice, doing any auto-adds? Added a process that runs through power users and looks at branches to auto give them rights to select groupings too so not as much admin manual work to give initial permissions, works nicely.

So far no - by design.

In the future - probably!

I do plan to set it so power users can delegate their page perms to anyone they want - but only pages that a superadmin permissioned them on.

Makes sense and seems a natural extension.