# Setting user permissions, where certain permissions imply other permissions

The purpose of the class is to set permissions for a user. These include delete, download, upload, view, etc. These properties often depend on other properties, and setting them has side effects.

For example, if I set CanUpload=false, then I need to also set CanManagePermissions=false since you cannot be an admin without upload permission. Likewise, if I set CanManagePermissions=true, then I need to set delete, download, and upload to true. Plus, you can't have CanDownload permission without also having CanView permission, so I set that too. But you can have CanView without CanDownload.

You can see this starts to get a bit convoluted. Especially when you through in account preferences that relax/tighten the relationships and force disable some of the permissions (which is important since I'm binding this to UI and want to enable/disable checkboxes).

The code works as-is, but it is very difficult to maintain and understand all of the relationships and side-effects. If someone is new to the code it can be a trip trying to figure out how properties depend on and change other properties (even more so when you get to doubly nested dependencies like CanManagePermissions->CanDownload->CanView).

Can I make the relationships any clearer or easier to work with? I'm assuming it's more than just an issue of documentation, but maybe not.

One thought was to have one big method that all of the setters call at the end. That one method would enforce all of the relationships. Not sure if this can satisfy every condition or if it's a good idea though.

public class AccessControlViewModel : INotifyPropertyChanged
{
private AccountPreferences Preferences => CurrentUser.Account.Preferences;

public AccessControl AccessControl { get; private set; }

public bool HasChanged { get; private set; }

{
get
{
}
set
{
{

if (!value)
{
CanManagePermissions = false;
if (EnableViewOnly)
{
CanView = true;
}
else
{
}
}

HasChanged = true;
RaisePropertyChanged(nameof(PermissionSummary));
}
}
}

{
get
{
}
set
{
{

if (!value)
{
CanManagePermissions = false;
if (!EnableViewOnly)
{
CanView = false;
}
{
}
}
else
{
CanView = true;
}

HasChanged = true;
RaisePropertyChanged(nameof(PermissionSummary));
}
}
}

public bool CanDelete
{
get
{
return AccessControl.CanDelete.GetValueOrDefault();
}
set
{
if (AccessControl.CanDelete != value)
{
AccessControl.CanDelete = value;
RaisePropertyChanged(nameof(CanDelete));

if (!value)
{
CanManagePermissions = false;
}
else
{
}

HasChanged = true;
RaisePropertyChanged(nameof(PermissionSummary));
}
}
}

public bool EnableViewOnly => Preferences.EnableViewOnly;

public bool CanView
{
get
{
return AccessControl.CanView.GetValueOrDefault();
}
set
{
if (AccessControl.CanView != value)
{
AccessControl.CanView = value;

if (!value)
{
}
{
}

HasChanged = true;
RaisePropertyChanged(nameof(CanView));
RaisePropertyChanged(nameof(PermissionSummary));
}
}
}

public bool CanManagePermissions
{
get
{
return AccessControl.CanManagePermissions.GetValueOrDefault();
}
set
{
if (AccessControl.CanManagePermissions != value)
{
AccessControl.CanManagePermissions = value;
RaisePropertyChanged(nameof(CanManagePermissions));

if (value)
{
CanDelete = true;
}
{
}

HasChanged = true;
RaisePropertyChanged(nameof(PermissionSummary));
}
}
}

{
get
{
}
set
{
{
HasChanged = true;
}
else
{
}

}
}

{
get
{
}
set
{
{

{
CanManagePermissions = true;
}

HasChanged = true;
}
}
}

public string PermissionSummary
{
get
{
//...Returns a string based on the above properties...
}
}

public event PropertyChangedEventHandler PropertyChanged;

private void RaisePropertyChanged([CallerMemberName]string propertyName = "")
{
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
}
}


I would definitely recommend moving all the logic from setters to single ValidatePermissions method, which should check every permission and, if the current state is invalid, correct them. This way it will be way easier to understand and maintain all the dependencies. You should also consider moving validation logic to your business layer, if having correct permissions setting is critical for your application. More often than not those settings are stored somewhere (DB, .ini file, cloud, etc.), and you don't want your application to break, just because those setting for whatever reason were modified outside your application.

Also, you don't have to use nameof() operator if you are using CallerMemberName attribute. You can just call RaisePropertyChanged() (without arguments).

AccessControl property is fishy. If it is actually a wpf control, than this is a major violation of MVVM. Your viewmodels should never have a direct access to view, thats what databinding is for. If it is not a UI control, then IMHO you should rename it, removing the Control word from both class name and property name. AccessManager sounds good to me.

• AccessControl is a model and comes from the SDK/API, so no changing that one. CallerMemberName came after a lot of the properties; it's on my list to update the older ones. Also, all of this logic is already in the server-side. I need it client-side solely for UI/design prettyness. I'm going to look more into a single method, but I think I'll run into issues where some properties get reset incorrectly. May 12, 2016 at 15:03
• In my one new method, if (CanManagePermissions) CanDownload=true; if (!CanDownload) CanManagePermissions=false; I need both rules but now I cannot uncheck CanDownload anymore. The ordering of the checks is very dependent on who triggered the call. I feel like I'm looking at this wrong. May 12, 2016 at 15:04
• Fair point. In that case you have to sacrifice something. You either keep your current approach and sacrifice readability. Or you reduce the complexity of your dependencies and use single method. For example you could eliminate the last use case completely, by disabling CanDownload checkbox when CanManagePermissions is set to true. May 13, 2016 at 7:08
• You can also change your approach completely (if that is an option). You could create a bunch of valid permission presets ("admin", "guest", "user", etc.) and instead of using a bunch of checkboxes, let user pick an existing preset from the list. Another option is to let user pick whatever the hell they want, but show a warning if they try to apply invalid combination of settings. May 13, 2016 at 7:14
• This is 'sorta' the route I'm going to. The other answers change much more than I'm willing to do right now. My one method is going to take in the property name and just switch on the name to carry out side-effects. Not much shorter, but it's easy to follow IMO. Posting as a separate answer for the curious. May 13, 2016 at 11:46

It appears that business logic (" I set CanUpload=false, then I need to also set CanManagePermissions=false since you cannot be an admin without upload permission") is being mixed up with the user interface presentation.

Your AccessControlViewModel should just be a strongly typed bag of data representing what the user has chosen on a form. After pressing a button, you should then validate the entries in the form.

After validation has passed, you really need a collection of classes that represents the "Problem Domain" - managing permissions, like say a User class:

public class User
{
public bool CanUpload { get; private set; }
public bool CanManagePermissions { get; private set; }

{
get { return CanManagePermissions; }
}

{
throw new InvalidOperationException("Cannot allow uploads without being able to manage permissions");

}

{
}

public void AllowPermissionManagement()
{
CanManagePermissions = true;
}

public void DisallowPermissionManagement()
{
CanManagePermissions = false;
}
}


User user = new User();

user.AllowPermissionManagement();
user.AllowUploads(); // No exception gets thrown

user.CanManagePermissions // Is True

user.DisallowPermissionManagement();

user.CanManagePermissions // Is False


You really need a separate of UI logic from Business Logic.

Instead of using bool properties, use bit flags with enumeration types. Just make sure that the values assigned to the different [permission] flags are in increasing powers of 2 (e.g. 0, 1, 2, 4, 8, 16, etc.)

enum Permissions { None = 0, CanView = 1, CanDownload = 2, CanManagePermissions = 4 }

class User { public Permissions Permissions { get; set; } }

...

• Flags don't work too well with UI layer. Binding a single enum value to a bunch of checkboxes while also validating all the possible combinations is a lot of converting with no actual profit. That being said, using flags in business layer is a good idea. May 12, 2016 at 14:46
• Oh, overlooked that this was in WPF, but bit flags are so universal. In this particular case, the validation would be about checking the sums of the values of the selected checkboxes and making sure that they match the sums of allowed combinations. May 12, 2016 at 14:51
• Yeah, checking the sums is clever, I like it! May 12, 2016 at 15:01
• You should fix your code though: in your example user.Permissions == Permissions.CanView will return false. You should use HasFlag method when checking for flags. May 12, 2016 at 15:02
• Ooh didn't think about using flags for this! I'll investigate that more; not quite sure how it will work when you add in account prefs and enabled/disabled-ness. May 12, 2016 at 15:12

Probably not the Modern (tm) approach, but I would set this these up with two layers: base permissions and effective or resolved permissions. You could implement this by having the get{} for a property check the dependencies of the current property with an AND (&&) to each property that it depends on.

This is what I'm going with. I changed all of the properties to be simple get/set with a backing field, and then listen to PropertyChanged to do the side-effects. I think it's more readable (enough so that I'm happy with it).

private void AccessControlViewModel_PropertyChanged(object sender, PropertyChangedEventArgs e)
{
var setHasChanged = false;
switch (e.PropertyName)
{
case nameof(CanView):
{
if (!CanView)
{
}
setHasChanged = true;
break;
}
{
{
CanView = true;
}
else
{
CanManagePermissions = false;
{
}
{
CanDelete = false;
}
}
setHasChanged = true;
break;
}
{
{
if (!EnableViewOnly)
{
}
{
CanDelete = false;
}
CanView = true;
CanManagePermissions = false;
}
setHasChanged = true;
break;
}
case nameof(CanDelete):
{
if (CanDelete)
{
CanView = true;
}
else
{
CanManagePermissions = false;
}
setHasChanged = true;
break;
}
case nameof(CanManagePermissions):
{
if (CanManagePermissions)
{
CanView = true;
CanDelete = true;
}
setHasChanged = true;
break;
}
{
setHasChanged = true;
break;
}
}
if (setHasChanged)
{
HasChanged = true;
{
}
{
}
RaisePropertyChanged(nameof(PermissionSummary));
}
}