Conditional show/hide for buttons

Comments

9 comments

  • Official comment
    Avatar
    Jessica Robinson

    Thank you all for your feedback above.  We have an Epic in the backlog which will be going through a Discovery period later on in the year to distil user requirements.  The objective of this Epic is to enable dynamic content configuration; where content/controls will be hidden/shown, or enabled/disabled, based certain conditions or parameters, including the user.

    I cannot comment on what the mvp will look like until we are a certain way through the Discovery, likewise I am currently unable to give a definitive timeline for making this functionality available.  However, I will keep you updated as we progress with the Discovery.  We will also likely be in touch to test some assumptions and designs with yourselves during this activity.

    Kind regards

    Jess

    Product Owner

    Comment actions Permalink
  • Avatar
    Karl Hertz

    We support this one. To generalise, we would like to be able to expose controls/elements/objects on a model depending on different states, e.g. "does the user belong to a certain user group".

    There have been multiple occasions where we have had to make what is essentially duplicate model masters with basically the same content, but one with controls for manipulation. It creates a paradigm which is harder than necessary to operate under. What we would like to do is make it so if you can edit "stuff" on the model, the things on the model has the look, feel and controls for that. If not, you have the look and feel of that instead. Without doing scripting on top of MooD, this is something which is really hard to achieve, currently (unless you build out two separate user experiences which become cumbersome to maintain).

    1
    Comment actions Permalink
  • Avatar
    Soren Staun

    This is a side issue to another issue:

    You cannot test for user permissions when designing menus either, i.e. there's no way to remove a menu item from a menu if the user doesn't have a specific role or a query returns a specific thing.

    We use jQuery to modify menus based on hidden infopanels. Same with buttons.

    if ($(".mood-node-name-access").text().trim()=="0")
        $(".mood-node-name-secret-button").css("visibility","hidden");

    Works on Rune's suggestion and similar style can be used for menus, but it's a lot of extra code to maintain at some point.
      

    0
    Comment actions Permalink
  • Avatar
    Matthew Dodd

    Hi Soren, just a note in case you didn't know this existed.. There's a Query construct for Permissions:

    Matt.

    0
    Comment actions Permalink
  • Avatar
    Rune Frits Kjerulff

    Thanks for all the feedback.

    @Søren, Maybe I'm misunderstanding something, but the server side show/hide that is possible for menu's is actually what i'd like to replicate in some form for buttons.

    As i see it there's roughtly two types of menues you can implement.

    1. Elements with models menu. i.e. Element type Screens, pages, models.
    In this case you can control whether or not the users can see and interact with the menu item through MooD permissions, and we usually set a permission on the highest possible level which then hides all of the underlying pages. The menu itself is basically just configured as a query that finds all pages and uses parenting to determine how it should output. So I'm assuming you're not referring to this type of menu.

    2. model master menu's, i.e. different tabs for a given element type.

    For this type of menu you can control whether or not the menu item is included on an individual model master level, and you can do this using standard query functionality. So for instance if i have an Application, and i have a Model master that shows Security details, then in the menu "Select models for elements" i can define a query for each model master which only returns the subject element if the user belongs to the Security permission group, if not the query returns nothing and the menu item is never populated towards the user.

    AFAIK there aren't really any limitations to this approach so one can feasibly have one single menu panel that returns model masters for various element types, and simply includes the relevant menu items if a query checking for element type returns an element.

    Are you referring to some other use case, or is there an issue with the approach outlined above that I'm blind to?

    Regarding the script for buttons. That's what I would currently be implementing as the workaround to show/hide buttons, however it's client side, so possible for the user to bypass, moreover it's very likely to go KABOOM at some point down the road when some hapless user (me) gets the bright idea to change the button name, accidently move the hidden fields out of canvas, or something silly like that.

    -Rune

    0
    Comment actions Permalink
  • Avatar
    Soren Staun

    @matt: I did not know that one, no, but unfortunately it doesn't help as many permission groups stem from your logged in user having a relationship to a project, an application or other things in the repository. They can be checked via simple queries, but they're not part of the permission system as such. 

    So I need to build a menu from a number of items, and then possibly add some and remove some based on the users relationship to the element, e.g. you're a project manager for the project you're looking at so you can see Master 1, Master 2 and Master 3 all giving great views into the data of the project, BUT you can also see an Edit Master or Financial data because you're in charge of THIS project (not all projects, but this one). 

    This also illustrates why we cannot use normal permission groups in MooD since it would require one permission group per relation between people and projects - that could be quite a few!

    @rune: I was referring to #2. Menus do not expose any pins so you cannot create a query that pins to the current user. All variables in menus are internal and hardcoded.

    1
    Comment actions Permalink
  • Avatar
    Karl Hertz

    @Soren Staun

    There is one thing here which I am 99% confident I have highlighted before (even though I cannot find it anymore) - the ability to control not just "model" but "model master" for different user groups.

    We basically need two things:

    1. User rights for Model Masters. Even though you have the right to view a particular element, if you do not have the right to view it through this particular Model Master ("lens"), I want to be able to redirect to "somewhere else". This can be even further expandend, so when I navigate from an element in (for instance) a matrix, not only can I set which Model Master you will arrive at the elemnt with, but I can set that Model Master according to your user group...

    2. The ability to (as you put it above) filter out things on a Model Master (and in other places) depending on user rights. When I say "filter out", I mean visually. The thing Matthew highlighted above can be used when the content is produced dynamically through queries (and I must admit I didn't know about this functionallity, so thanks @Matthew Dodd), but when there is (for instance) a button which should only be visible for people being able to interact with that button, we run into the realm of "cannot be done" or "can only be done with scripting".

    1
    Comment actions Permalink
  • Avatar
    Matthew Dodd

    This is all useful feedback and I have linked our existing stories to this conversation:

    Another thought in this area.. There are also Conditional Model Masters which can use Queries starting from the connected user.

    0
    Comment actions Permalink
  • Avatar
    Soren Staun

    Good input above, Karl. Didn't see the @tag since Zendesk is Zen, but not very powerful ;-)

    I think the main point here, which is important!, is that using JavaScript to modify who can do or see what is effectively insecure. Anybody with a browser console can circumvent it if they practice a bit. Security needs to be server side.

    0
    Comment actions Permalink

Please sign in to leave a comment.