Moving uSync to new section or alternative ideas

ultim8pedigree · August 24, 2025, 2:59am

Hello,

We have a necessity to hide the settings for a user group but then they don’t have uSync. So I’m trying to either move uSync to a new section or have some alternative idea in the settings (i.e., hide all settings subsections on the left pane and only showing uSync). I’ve tried a few things but particularly I am unable to load a JavaScript when a user is in settings. I’m super open to suggestion (particularly one that accomplishes what we’re trying to do).

KevinJump · August 24, 2025, 7:10am

Hi,

So this was a pain but is technically possible with Umbraco v13 i am not sure its something that will work with Umbraco v16 .

You probably can add code for a custom section and move the uSync tree into that section with some front end code. but the back end api’s are restricted to people who have access to the settings section, so it won’t work when it gets there.

Long explanation

Unless i am wrong - under v13 the backend (c#) code knows about the tree’s and where they are in the UI and the security settings on APIs are restricted to ‘TreeAccess’ so if you move the tree between sections then in theory as long as the user has Tree access it all still works.

Under v16 however the backend only knows about sections. (well it knows of sections) security it applied at the section level, so moving things in the UI doesn’t work the same.

I’ve checked in the Umbraco source about this, and while it still have lots of “TreeAccess” level security definitions (as does uSync!). when you trace them to their definitions they are creating with section level access.

For Example Languages is set with a policty of AuthorizationPolicies.TreeAccessLanguages but the AddAllowedApplicationsPolicymearly sets it to section level access

github.com/umbraco/Umbraco-CMS

src/Umbraco.Cms.Api.Management/DependencyInjection/BackOfficeAuthPolicyBuilderExtensions.cs

1085eebb8


      
              builder.Services.AddSingleton<IAuthorizationHandler, UserPermissionHandler>();
              builder.Services.AddSingleton<IAuthorizationHandler, AllowedApplicationHandler>();
              builder.Services.AddSingleton<IAuthorizationHandler, BackOfficeHandler>();
          
              builder.Services.AddAuthorization(CreatePolicies);
              return builder;
          }
          
          private static void CreatePolicies(AuthorizationOptions options)
          {
              void AddAllowedApplicationsPolicy(string policyName, params string[] allowedClaimValues)
                  => options.AddPolicy(policyName, policy =>
                  {
                      policy.AuthenticationSchemes.Add(OpenIddictValidationAspNetCoreDefaults.AuthenticationScheme);
                      policy.Requirements.Add(new AllowedApplicationRequirement(allowedClaimValues));
                  });
          
              options.AddPolicy(AuthorizationPolicies.BackOfficeAccess, policy =>
              {
                  policy.AuthenticationSchemes.Add(OpenIddictValidationAspNetCoreDefaults.AuthenticationScheme);
                  policy.Requirements.Add(new BackOfficeRequirement());

So technically if things are set there the API’s are section limited.

That all said (while i was working this out) we might be able to make the uSync access limited to settings and a as yet undefined section. e.g. “Synchronization” or something then it would still work as required but if the section was created uSync could be moved into it…

I will try this you never know…

KevinJump · August 24, 2025, 7:55am

So this PR (below) creates a new section and changes the permissions on the front and the back end, so anyone with access to settings or this new section will have permission to view and run the uSync commands.

github.com/KevinJump/uSync

Add a custom section with the uSync tree in it

v16/main ← v16/custom-section

opened 07:53AM - 24 Aug 25 UTC

KevinJump

+17 -2

Adds a custom section, that when enabled will show the uSync tree. This secti…on isn't required as the tree also appears in Settings. so for most people it will be fine. but if you want to 'move' things to a new section this would do it. Ideally we would also have something that removes it from the settings tree, A condition might do this, but it needs to be section aware (e.g know that we are currently rendering the 'settings' section). I think this might be possible, not yet sure.

It does mean you end up with the usync tree in settings and the new section but i having a think about that. once i’ve figured that bit out we might push this into a v16 release

KevinJump · August 24, 2025, 5:20pm

Have an update for this now.

the PR has been updated so we will have a setting, then when used will turn the custom uSync section on, and remove the uSync menu from the settings section .

github.com/KevinJump/uSync

Add a custom section with the uSync tree in it

v16/main ← v16/custom-section

opened 07:53AM - 24 Aug 25 UTC

KevinJump

+17 -2

Adds a custom section, that when enabled will show the uSync tree. This secti…on isn't required as the tree also appears in Settings. so for most people it will be fine. but if you want to 'move' things to a new section this would do it. Ideally we would also have something that removes it from the settings tree, A condition might do this, but it needs to be section aware (e.g know that we are currently rendering the 'settings' section). I think this might be possible, not yet sure.

nightly build of this version on our nuget feed.

ultim8pedigree · August 24, 2025, 9:53pm

Super duper thank you for your reply. And I’m happy to open a new project to test with and proof out these concepts. i’ll look into pulling from the night build. once i follow up on your comments and can pull it.

in the mean time! because there is no time like the current time. i’m tasked with and have a time window for the client with this project. i’m pushing for it because, frankly, umbraco looks good. but, the timing of this to work with and proof based off the nightly build might not fit (right now). i still have a couple months??? so i might be able to impliment if feasible.

i’ve dug around and found similar things people wanted to do like me. one of the avenues though hasn’t born fruit, was to try adding some javascript and/or css into the back office that simply ‘hid’ the section nodes i want to hide under settings. because again, in this instance, i only want usync to be visible. i don’t want people to see the other options under settings. security isn’t an issue as this is just to prevent ‘accidents’. it is a trusted enviornment

might i be able to check with you the feasibility? and or get some high level pointers on how we can go about doing this? it seems with v16, i’m having issues adding javascript files and css. i have some success. but the oddest things are like my console.log files in my javascript don’t show in the developer console window (f12). so it looks like the javascript isn’t ran. i haven’t narrowed down which method (js or css) is the one actually working doing weird stuff like not showing tree nodes for all the sections. they’re only concerned with not having anything showing in settings, only uSync.

thanks for your time. i’m hoping to get more familiar with the project, nuances, and it’s future!

nielslyngsoe · August 25, 2025, 7:37am

Hi @ultim8pedigree

Its a bit hard to pitch in on why your JS does not run, but maybe my suggestion will give you pointers enough to move on.

For v.16 the Extension Registry gives you the flexibility to Exclude extensions, which i was I thinking you could utilize. As you mention your self it will not give any security, just hide the UI.

Read about it here:

To get some JS to run on application-level, when logged in, look at this extension type:

Then there is a bit of uncertainty, like what factors you want to utilize to hide uSync. I think the simplest may be checking the current user for some information already available.

It could be wether its admin:

Or if it has access to sensitive data:

Or what sections it has access to:

To utilize the Current User Context, you need to learn about the Context API.
For an Entry Point, it is a little different as you are not a Controller, but you can use the first argument to the onInit method, which is a host reference:

...

export default class MyEntryPoint {
	onInit (host: UmbElement, extensionRegistry: UmbExtensionRegistry<ManifestBase>) {
		host.consumeContext(UMB_CURRENT_USER, (context) => {
			// ...
		});
	}
}

KevinJump · August 25, 2025, 9:26am

Hi,

Assuming it doesn’t cause any issues we will release this fairly quickly, we are only not doing it today because it’s a public holiday in the UK.

Also while i am sure all the stuff @nielslyngsoe says would help you manipulate the appearance and location of the uSync dashboard on the front end, on the current releases that still isn’t going to work for you.

The backend (c#) controllers that uSync uses to perform all the actions are restricted to users who have access to the settings section only. so if you move the front end with javascript the backend will just not work.

On previous versions (v13 or lower) you could move the tree because access within the c# was tied down by tree not section, this isn’t true in v14+ so that’s why it won’t work.

we will likely have the full release with this in ready tuesday/wednesday, which i am guessing will be quicker than getting you head around all the new backend stuff anyway. (that will also not work in this case).