We have moved to GitHub Issues
Created by Gabriel Ionut 31 Jan 2017, 10:40:32 Updated by Sebastiaan Janssen 08 Nov 2017, 07:56:50
Subtask of: COU-521
Umbraco 7.5.4: If we set up a new UserType (Editor, Writer, Translator or even a custom one), they do not have the right to deploy even if all the sections under User Name are checked and under courier security, proper access granted and Saved.
In the moment when we check the security access again for a given User (Editor, Writer, Translator) all the boxes are unchecked.
On the new version of Umbraco when I try to give proper access for a given User I get the following errors:
System.Data.SqlServerCe.SqlCeException (0x80004005): The specified table does not exist. [ UCUserSettings ] at System.Data.SqlServerCe.SqlCeCommand.ProcessResults(Int32 hr) at System.Data.SqlServerCe.SqlCeCommand.CompileQueryPlan() at System.Data.SqlServerCe.SqlCeCommand.ExecuteCommand(CommandBehavior behavior, String method, ResultSetOptions options) at System.Data.SqlServerCe.SqlCeCommand.ExecuteNonQuery() at StackExchange.Profiling.Data.ProfiledDbCommand.ExecuteNonQuery() at Umbraco.Core.Persistence.PetaPocoCommandExtensions.<>c__DisplayClass1.b__0() at Umbraco.Core.Persistence.FaultHandling.RetryPolicy.ExecuteAction[TResult](Func`1 func) at Umbraco.Core.Persistence.PetaPocoCommandExtensions.ExecuteNonQueryWithRetry(IDbCommand command, RetryPolicy cmdRetryPolicy, RetryPolicy conRetryPolicy) at Umbraco.Core.Persistence.PetaPocoCommandExtensions.ExecuteNonQueryWithRetry(IDbCommand command, RetryPolicy retryPolicy) at Umbraco.Core.Persistence.PetaPocoCommandExtensions.ExecuteNonQueryWithRetry(IDbCommand command) at Umbraco.Core.Persistence.Database.Execute(String sql, Object args) at Umbraco.Courier.UI.Security.UserSettingsStorage.ClearSettings(Object userid) at Umbraco.Courier.UI.Pages.editCourierSecurity.saveSettings_Click(Object sender, ImageClickEventArgs e) at System.Web.UI.WebControls.ImageButton.OnClick(ImageClickEventArgs e) at System.Web.UI.WebControls.ImageButton.RaisePostBackEvent(String eventArgument) at System.Web.UI.WebControls.ImageButton.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument) at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) at System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
We are on Umbraco 7.5.8 and Courier 3.0.4 and I am experiencing these same issues. I have to make users Administrators in order for them to deploy content with Courier. Every time I've tried to update the Courier Security settings for any user in the Users section, the settings are never saved.
We have the same issue - it says it saved the settings but it doesn't actually save.
We're encountering something similar on Umbraco 7.5.11 / Courier 3.0.7 (upgraded from 7.4.3/2.52.4)
We have the UCUserSettings table.
When I visit the Courier permissions table for any non-admin user, the settings are always entirely blank. If I set a permission and press save, I can see the permission has been persisted correctly to the UCUserSettings table. If I refresh the page the settings are no longer set.
If I perform the same task on an admin user, on initial load the page always shows the settings as checked. If I uncheck and save, the settings are correctly persisted but are again checked on refresh.
Only admin users can perform any couriering, no matter what settings are in the database.
I believe that Courier is not correctly reading settings from the USUserSettings table and is instead creating UserSettings in memory that are based on the defaults for the user type (admin/non-admin).
I believe I have a workaround for this problem.
By debugging a refresh of the courier permissions page (editCourierSettings.aspx) with all exception breakpoints enabled, I witnessed a repeatable RuntimeBinderException in Umbraco.Courier.UI.Security.UserSettingsStorage.GetSettings(). This method appears to be loading all permissions from a user (based on sql traces). The exception implies that the code in this method is calling for dynamic properties that do not exist on the returned objects. By 'do not exist' I mean do exist, but are spelled incorrectly.
A guess led me to rename the 'Value' and 'Key' columns (as created in the current Courier sql install file) to 'value' and 'key'. This, amazingly, seems to have resolved the problem entirely.
I have reason to believe that the RuntimeBinderException is caught in the GetSettings() method and an empty list is returned with no logging. I'll leave it to you to determine whether this is appropriate in commercial closed-source software.
So, running something like:
sp_rename 'UCUserSettings.Key', 'key', 'COLUMN'; GO sp_rename 'UCUserSettings.Value', 'value', 'COLUMN'; GO
ALTER TABLE UCUserSettings DROP CONSTRAINT PK_UCUserSettings; GO
ALTER TABLE UCUserSettings ADD CONSTRAINT PK_UCUserSettings PRIMARY KEY CLUSTERED ( [User] ASC, [key] ASC )WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF); GO may also solve the problem for you until the Courier devs fix this.
First thing to note is that the courier tables including the
UCUserSettings are created when you install the Courier package in the back office. If you don't have this table it means that this package was not properly installed, or, you've installed it on a different environment and then pushed those changes upstream which would mean the installer will not execute. I've attached a screenshot of the post package installation screen. If you don't have this table, you should install the Courier package via the back office, please also make sure you are running the latest Courier version (we release new ones all the time that fix a multitude of issues).
I'll investigate the issue of persisting/retrieving these values and make sure this table is working correctly, stay tuned.
Ok here's what I've done:
dynamicwhen fetching records from the DB from UCUserSettings that was incorrect as noted by @BrettLawrence . This has been fixed to use poco objects correct, I'm fairly sure (but not 100% positive) that even if you've used Brett's work around to change the column name casing, the updated could could still work, otherwise you'll need to revert the column name casing back to what they were before
I've verified that you can assign/unassign the permissions in the User/Courier Security editor for any user and that a non-admin user when given the correct permissions can use Courier to transfer items.
PR for review: https://github.com/umbraco/UmbracoDeploy/pull/110
screenshot of dashboard
Backwards Compatible: True
Affected versions: 3.0.3
Due in version: 3.1.5
Sprint: Sprint 66