I am configuring NLS for a client who wants to test it out using the trial version before confirming it suits their needs and they purchase a license. I have two workspaces set up (one for them to try out and one for me to learn how it works/to configure etc).
Workspace access seems to allow for user based and group based access and my client want's NLA to only be accessible by their Umbraco user (or at least on administrators) for the time being whilst he is testing it.
However, I seem unable to configure this?
Setting no users or groups to have access states that all back-office users get access:
Attempting to select the 'Administrators' group to be the only group to have access states this is an invalid selection (as they have access to everything by default):
Attempting to select 1 or more individual users shows a ticked checkbox next to their name, but no save button (just close), a JS error in the console and seemingly nothing has taken effect if you select the user and then 'close' the sidebar:
Am I missing something here? At the moment, it seems like the most restrictive I can make this is allowing all back-office 'Editors' access to the workspace(s)?
First of all, it looks like a breaking change in the core User Picker is what is causing the issue with selecting a given User - I'll make sure that this gets addressed in an upcoming release.
Let's see if we can find a way around this in the meantime.
You basically have two main options when it comes to restricting access.
Application/Section level access
This is a core Umbraco-feature that allows you to restrict access to any section in the backoffice. If you want to totally disable access you can use this setting to hide the "Email"-section from the top menu for this user.
Workspace Permissions
Like you said, the idea is that when there is no permissions configured everyone will have access to this Workspace. As soon as you setup any kind of permissions these will be applied for all users except for the administrator.
So if you want to restrict the access for all users except the you could use for example add a User Group that you're not using for any of your Users for example "Translators" and then uncheck all the boxes.
This would allow all Users in the "Translator"-group access to the Workspace but they would not have any permissions assigned. This will also mean that no other user will have access to the Workspace since no user is in the "Translator" group. If you are using the "Translator"-group in your solution my example would also apply if you created a new User Group called e.g. "No Access" and applied the permissions to this group.
In the future when you're client wants to give access to other Users you can add them to a User Group and use this to control the permissions.
Thanks for the swift response. I have implemented your proposed workaround for now of assigning the Translators group (which I wasn't using) and unchecking all the permissions. So if I understand correctly, now only 'Administrators' should be able to access the workspace(s).
I'll keep an eye out for the fix/update to resolve the User Picker issue.
Just to clarify, even once that issue is fixed, assigning access to an individual user will not prevent any/all other users in the Administrators group from accessing then? e.g. It's not possible to restrict access to one and only one user (at least not without removing everyone else from the Administrators user group)?
I don't really expect that to be an issue in practise, just making sure I understand how it works and that Admins will always have access no matter what.
Yes, in this case any other user would not see this tree in they are not in the "Administrators" group.
Already working on the fix so it should be out in the next couple of days.
Administrators will always have access to everything if you need restrictions on a user that is an administrator your only way to address this is to create another group e.g. "Less Administrator" and set permissions. Any user in the Administrator group will always have access to everything.
Don't hesitate to reach out if you need further explanations or have other questions!
I upgraded to v3.0.6 the other day (as per some of our other comms) but I think I am still seeing the User Picker bug you mention above:
First of all, it looks like a breaking change in the core User Picker
is what is causing the issue with selecting a given User - I'll make
sure that this gets addressed in an upcoming release.
Have you been able to make any progress with this and if solved in a v4.x branch, could this be applied to v3 too please?
We are using Umbraco v8.18.4, so based on your reference in your NLS v3.0.4 changelogs, would expect to have been effect whilst on NLS v3.0.3 but resolved now I am on NLS v3.0.6 as per your fix.
I am still getting the exact same issue in the console that I screenshot above.
In terms of 'Cleared browser cache etc' I get this with Chrome Dev Tools open and 'Disable Cache' ticked and have explicitly loaded my sites DependencyHandler.axd file in a new tab and forced a hard reload of this file from the server, so assuming it's the one causing the issue, I wouldn't expect it to be outdated.
In terms of 'make sure to reset all client files, update clientDependency etc' i'm not too sure what you mean here?
I am not very familiar with the 'Client Dependency' features/purpose if I'm honest. I believe this is used to manage caching/versioning of client-side resources like JS files? I think it does nothing in debug mode but is enabled in production, as I think I had some issues on go live for this project where I needed to alter or workaround this for my frontend assets, but from memory I left everything as it was for back-office assets (else i'd imaging much more of my back-office would be exhibiting issues)
Any idea how I might go about debugging further?
I will try and dig out a record of what, if anything, I changed re: Client Dependency config 18 months ago for go-live.
I have double-checked that the fix was included in v3.0.6 and tried replicating the issue on Umbraco v8.18.4 without success, for me it looks like this:
So I think this comes down to an issue with caching. So ClientDependency is a client asset framework/helper built by former Umbraco HQ-member Shannon Deminick. Umbraco uses it to bundle javascript files loaded into the backoffice. It's been used ever since Umbraco v4 up until v8 (v9+ uses something else Smidge that is built for .NET "Core").
So, when on .NET framework and the website does NOT run in "debug mode" (that is debug=true in web.config) the ClientDependency framework will store a bundled snapshot of all client files (javascript files in the backoffice) in a cache-folder on disk to and serve this bundled file in one request. This "snapshot" has a version that is configured in the /config/clientDependency.config:
So if you change the content of any of the js-files used in the backoffice on a website in production mode nothing will happen if the clientDependency version is kept. The old versions of the files will be served when if the content on disc has changed. So one needs to go into this file and just change the number, in the screenshot above changing 3 to 4 would force a refresh of the cache. If you for example upgrade Umbraco it will touch this version automatically.
So, to make sure you're client files are up to date, please try to:
Bump the version in your clientDependency.config
Restart the website
Reload the backoffice with DevTools open (and cache disabled).
If you're working with the website in debug mode (web.config debug=false) ClientDependency should not be activated so no need to worry in that case.
As a side note: On client projects we have a build step in our release pipeline that always sets the clientDependency version to the release number for the build server. That way we know that we won't have strange issues due to this cache.
I have reviewed on UAT (where the application is running in debug mode currently) and this functionality works there.
I can also see from my GIT history that our Client Dependency Version identifier hasn't been updated/bumped since my last Umbraco upgrade in June.
I am therefore almost certain that you are correct and updating this CDF version number will fix the issue we see in production (which is the use of stale/cached JS/CSS assets in us in the Umbraco back-office).
I have made this update but am yet to release it into production to confirm, though I am extremely confident it will fix the issue.
For clarity, I've reviewed the changes I referenced making re: CDF at time of launch for this product and can see that this was the use of Html.RequireCss and Html.RequireJs in my frontend .cshtml templates which I replaced with my own solution of my pre-bundled frontend assets with my own 'cache buster' version query param on the end.
Your suggestion of adding a build/pipeline step to increment the CDF number would also have been a solution to my original issue as it happens (essentially I didn't understand what CDF was doing at the time and why I was getting stale frontend assets).
Sounds like CDF is the problem here, indeed. We used to use CDF for some of the public sites that we made before pre-compilers was a part of every project. Today we don't use CDF for frontend websites but we do use the release-number as cache buster.
Please let me knot if the CDF-version adjustments solves the problem for you.
Unable to Restrict NLS Workspace Access Correctly
Umbraco: v8.18.4
NLS: v3.0.3
I am configuring NLS for a client who wants to test it out using the trial version before confirming it suits their needs and they purchase a license. I have two workspaces set up (one for them to try out and one for me to learn how it works/to configure etc).
Workspace access seems to allow for user based and group based access and my client want's NLA to only be accessible by their Umbraco user (or at least on administrators) for the time being whilst he is testing it.
However, I seem unable to configure this?
Setting no users or groups to have access states that all back-office users get access:
Attempting to select the 'Administrators' group to be the only group to have access states this is an invalid selection (as they have access to everything by default):
Attempting to select 1 or more individual users shows a ticked checkbox next to their name, but no save button (just close), a JS error in the console and seemingly nothing has taken effect if you select the user and then 'close' the sidebar:
Am I missing something here? At the moment, it seems like the most restrictive I can make this is allowing all back-office 'Editors' access to the workspace(s)?
HARVS1789UK
Hi!
Thanks for looking at the package!
First of all, it looks like a breaking change in the core User Picker is what is causing the issue with selecting a given User - I'll make sure that this gets addressed in an upcoming release.
Let's see if we can find a way around this in the meantime.
You basically have two main options when it comes to restricting access.
Application/Section level access
This is a core Umbraco-feature that allows you to restrict access to any section in the backoffice. If you want to totally disable access you can use this setting to hide the "Email"-section from the top menu for this user.
Workspace Permissions
Like you said, the idea is that when there is no permissions configured everyone will have access to this Workspace. As soon as you setup any kind of permissions these will be applied for all users except for the administrator.
So if you want to restrict the access for all users except the you could use for example add a User Group that you're not using for any of your Users for example "Translators" and then uncheck all the boxes.
This would allow all Users in the "Translator"-group access to the Workspace but they would not have any permissions assigned. This will also mean that no other user will have access to the Workspace since no user is in the "Translator" group. If you are using the "Translator"-group in your solution my example would also apply if you created a new User Group called e.g. "No Access" and applied the permissions to this group.
In the future when you're client wants to give access to other Users you can add them to a User Group and use this to control the permissions.
Not sure if this answers your question?
Hi Markus,
Thanks for the swift response. I have implemented your proposed workaround for now of assigning the Translators group (which I wasn't using) and unchecking all the permissions. So if I understand correctly, now only 'Administrators' should be able to access the workspace(s).
I'll keep an eye out for the fix/update to resolve the User Picker issue.
Just to clarify, even once that issue is fixed, assigning access to an individual user will not prevent any/all other users in the Administrators group from accessing then? e.g. It's not possible to restrict access to one and only one user (at least not without removing everyone else from the Administrators user group)?
I don't really expect that to be an issue in practise, just making sure I understand how it works and that Admins will always have access no matter what.
Hi!
Yes, in this case any other user would not see this tree in they are not in the "Administrators" group.
Already working on the fix so it should be out in the next couple of days.
Administrators will always have access to everything if you need restrictions on a user that is an administrator your only way to address this is to create another group e.g. "Less Administrator" and set permissions. Any user in the Administrator group will always have access to everything.
Don't hesitate to reach out if you need further explanations or have other questions!
Cheers!
Hi Markus,
I upgraded to v3.0.6 the other day (as per some of our other comms) but I think I am still seeing the User Picker bug you mention above:
Have you been able to make any progress with this and if solved in a v4.x branch, could this be applied to v3 too please?
Hi!
Hmm.. did not realize that these changes has been back ported to Umbraco v8.
I'll check for sure.
Will keep you posted.
@Joe, can you confirm what version of Umbraco 8 you are running?
There was a fix for this included in Newsletter Studio v3.0.4:
https://www.newsletterstudio.org/versions/3/
Did you make sure to reset all client files, update clientDependency etc after the upgrade? Clear any browser cache and so on?
Or maybe there is something else going on here, are you seeing the exact same error in the developer console?
Hi Markus,
We are using Umbraco v8.18.4, so based on your reference in your NLS v3.0.4 changelogs, would expect to have been effect whilst on NLS v3.0.3 but resolved now I am on NLS v3.0.6 as per your fix.
I am still getting the exact same issue in the console that I screenshot above.
In terms of 'Cleared browser cache etc' I get this with Chrome Dev Tools open and 'Disable Cache' ticked and have explicitly loaded my sites DependencyHandler.axd file in a new tab and forced a hard reload of this file from the server, so assuming it's the one causing the issue, I wouldn't expect it to be outdated.
In terms of 'make sure to reset all client files, update clientDependency etc' i'm not too sure what you mean here?
I am not very familiar with the 'Client Dependency' features/purpose if I'm honest. I believe this is used to manage caching/versioning of client-side resources like JS files? I think it does nothing in debug mode but is enabled in production, as I think I had some issues on go live for this project where I needed to alter or workaround this for my frontend assets, but from memory I left everything as it was for back-office assets (else i'd imaging much more of my back-office would be exhibiting issues)
Any idea how I might go about debugging further?
I will try and dig out a record of what, if anything, I changed re: Client Dependency config 18 months ago for go-live.
Hi!
I have double-checked that the fix was included in v3.0.6 and tried replicating the issue on Umbraco v8.18.4 without success, for me it looks like this:
So I think this comes down to an issue with caching. So ClientDependency is a client asset framework/helper built by former Umbraco HQ-member Shannon Deminick. Umbraco uses it to bundle javascript files loaded into the backoffice. It's been used ever since Umbraco v4 up until v8 (v9+ uses something else Smidge that is built for .NET "Core").
So, when on .NET framework and the website does NOT run in "debug mode" (that is debug=true in web.config) the ClientDependency framework will store a bundled snapshot of all client files (javascript files in the backoffice) in a cache-folder on disk to and serve this bundled file in one request. This "snapshot" has a version that is configured in the
/config/clientDependency.config:So if you change the content of any of the js-files used in the backoffice on a website in production mode nothing will happen if the clientDependency version is kept. The old versions of the files will be served when if the content on disc has changed. So one needs to go into this file and just change the number, in the screenshot above changing 3 to 4 would force a refresh of the cache. If you for example upgrade Umbraco it will touch this version automatically.
So, to make sure you're client files are up to date, please try to:
If you're working with the website in debug mode (web.config debug=false) ClientDependency should not be activated so no need to worry in that case.
As a side note: On client projects we have a build step in our release pipeline that always sets the clientDependency version to the release number for the build server. That way we know that we won't have strange issues due to this cache.
You can read more about this here:
https://www.enkelmedia.se/blogg/2012/9/1/umbraco-och-client-dependency-framework/
https://adolfi.dev/blog/umbraco-bump-cdf/
I will also look into the possibility of adding an installation/upgrade step that bumps this version if possible.
Please let me know if this solves your problem!
Hi Markus,
I have reviewed on UAT (where the application is running in debug mode currently) and this functionality works there.
I can also see from my GIT history that our Client Dependency Version identifier hasn't been updated/bumped since my last Umbraco upgrade in June.
I am therefore almost certain that you are correct and updating this CDF version number will fix the issue we see in production (which is the use of stale/cached JS/CSS assets in us in the Umbraco back-office).
I have made this update but am yet to release it into production to confirm, though I am extremely confident it will fix the issue.
For clarity, I've reviewed the changes I referenced making re: CDF at time of launch for this product and can see that this was the use of
Html.RequireCssandHtml.RequireJsin my frontend .cshtml templates which I replaced with my own solution of my pre-bundled frontend assets with my own 'cache buster' version query param on the end.Your suggestion of adding a build/pipeline step to increment the CDF number would also have been a solution to my original issue as it happens (essentially I didn't understand what CDF was doing at the time and why I was getting stale frontend assets).
Many thanks for your helpful input as usual.
Cheers,
HARVS1789UK
Hi!
Sounds like CDF is the problem here, indeed. We used to use CDF for some of the public sites that we made before pre-compilers was a part of every project. Today we don't use CDF for frontend websites but we do use the release-number as cache buster.
Please let me knot if the CDF-version adjustments solves the problem for you.
All the best!
// m
is working on a reply...