Permissions-based views

[Reed Law]

With logic-less views, how do you handle permissions? That is, if one kind of user role is allowed to see certain UI elements, but other roles are not, should the logic to hide/show a template be included in the view itself? Or is there a better place to put this logic? One possible solution would be to have the interactor check the user's authorization and the return the name of the template to be rendered by the view. This would remove the logic from the view but create a dependency from the interactor to the template's name.

[George Dinwiddie]

Hi, Reed,

I've done this before by using collections in the model, and iterating
in the view. If the user should not see something, the back-end code
returns an empty collection for that data.

"The model calculates; the view iterates." --Alex Chafee

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Reed Law]

George,

That is indeed what I'm doing when I need to render a collection of objects. But what I'm talking about here are UI elements such as a widget, button, etc. I don't want to sprinkle if current_user.role == "manager" throughout my views.

[George Dinwiddie]

Reed,

On 12/16/13 10:32 AM, Reed Law wrote:
> George,
>
> That is indeed what I'm doing when I need to render a collection of
> objects. But what I'm talking about here are UI elements such as a
> widget, button, etc. I don't want to sprinkle if current_user.role ==
> "manager" throughout my views.

I would not, either. I might, however, have a collection of "user
capabilities" that drove the selection of UI elements that support those
capabilities.

- George

> --
> The only way to go fast is to go well.
> ---
> You received this message because you are subscribed to the Google
> Groups "Clean Code Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clean-code-discu...@googlegroups.com.
> To post to this group, send email to clean-code...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clean-code-discussion.

[Faisal Arbain]

In Ep.06 of Clean Code (Test Driven Development Part 2) UB suggest to separate GUI into 2 part , Presenter and View. Presenter will massage the data and provide view flags whether to show or hide elements etc and view will just render the details. By separating  presenter from view, we can write test for our presenter.

[Reed Law]

Assuming that Interactors/Controllers only return simple data objects to the view, how would these "user capabilities" be presented? Views don't need a whole array of capabilities. The view only needs to know which template to load (or not to load in the case that a UI element should be hidden for a particular role).

[Caio Fernando Bertoldi Paes de Andrade]

Reed,

So you have two actors (e.g. user and admin) accessing the same view? That sounds a lot like a violation of the SRP.

I would separate one view for each role, and make the UI elements reusable to both to avoid duplication.

Hope this helps,

Caio

—
Sent from Mailbox for iPhone

[George Dinwiddie]

Reed,

If you're just loading a page template based on role, then that should
be pretty simple. Something like (pseudo-code):

#include /pages/${data-model.user-role}

[Reed Law]

Yes, this is usually the case throughout an app. For instance, an owner has one nav menu, while a manager has another. And from another view, there is a link to manage payroll which is a different link depending on whether the current user is a location manager, a department manager, or an HR manager. Of course, the links could point to the same endpoint (e.g. '/payroll') but still there has to be some place to keep the logic that determines what is rendered on a page in a more fine-grained sense. There are little UI elements like breadcrumbs that need to change depending on the role of the user.