In an MVP application, what should be the most appropriate way to implement restriction to some UI actions based on the current user's privileges?
For example, in a role-based security, different roles will have different access to some UI interactions on the same view. If, for instance, we have an online store, on the products list page the customers can only view the details and add items to their cart, but an administrator must be also presented with Add Product
buttons and Delete
button on each item.
Similar question has been asked here already, but the OP is asking for the UI making the permission checks. I am certain the UI (view) should not be responsible for permission validation, but still it has to know whether to visualize or not certain UI components. So, is there any well-defined or widely adopted pattern for telling the view which UI interactions it should disallow? I can think of a few solutions, but if there is a standard and proven one, I'd prefer to stick with that, rather than reinventing the wheel.
Update
To clarify a bit further, as suggested in answers below, I am considering the approach of having the view accept the privileges information from the presenter. It is the form of that information that bothers me - if using flags as bit masks or some too-generic representation I will:
- (+) Gain consistency in passing the permissions to the view
- (-) Couple the view with logic for resolving the flags.
The other thing I have in mind is having the View expose all the flags it needs as settable properties for the presenter (like view.IsDeleteItemAllowed
). So I will:
- (+) Not have additional logic for the permissions in the view
- (-) Add additional complexity to presenter to adapt permission flags to the view's properties.
So, I am thinking of using the later approach, because that way I can reuse the presenter with different view implementations; and will not rely on the view for understanding the permissions system (which may be a subject of changes). Is there anything I should worry about with that?