MVP Pattern - Ways to restrict the user action based on security privilleges

Question

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:

1. (+) Gain consistency in passing the permissions to the view
2. (-) 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:

1. (+) Not have additional logic for the permissions in the view
2. (-) 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?

Answer 1

I don't think there is a specific pattern for this. There are two obvious solutions to this:

1. The Presenter provides flags/a value to the View telling it the privilege level of the current user.
2. The View requests the CurrentUser Model object for its privilege level/if it has privilege X.

Which of those two gets used should mostly depend on how much interaction you allow between the View and the Model (i.e. can the View ask information from the Model, or should it all be provided by the Presenter).

Whether to use flags or a single value should depend on the design of your privilege system. For a set of privileges that can be independently granted or denied, a set of flags would be most useful. For increasing levels, where level X+1 can do everything of level X plus some more, I would go for a single value.

---

Update

If your permission system is subject to change, the best way to keep those changes out of the View is to give the View its own permission system based on fine-grained flags (isInsertionAllowed, isDeletionAllowed, etc.) and let the Presenter map between the two permission systems.

What you should watch out for with using individual properties is that, if a View needs an additional property after a modification, the Presenter for that View also needs to be updated.

Also note that when I talk about flags, this can be implemented either as bit-flags, or as boolean properties/arguments. That does not really make a difference for the design.