Hiding tabs based on user privilege(s) Question

0
I have a requirement to only allow users with specific Roles to see or modify specific content. I'm planning on using Tab objects to organize the content and control access. There are 11+ Roles and 6+ tabs, which (AFAIK) rules out using TT/SBM Sections. I can control access during Transitions via Group memberships, but the State display is the tricky part. Reports are a whole 'nuther can of worms.

I'm thinking that a combination of a custom State form with Javascript & the "$SCRIPT()" tag calling MashupScript. MashupScript will iterate each of the Roles and determine if the current user has that role and emit (via Ext.WriteStream) JavaScript that will enable the appropriate tab.

Anyone try anything like this before? (SBM 2009 R2)
Responses (8)
  • Accepted Answer

    Tuesday, January 11 2011, 11:15 AM - #Permalink
    0
    At first glance, that sounds like it would work. I haven't tried using MashupScript to write JavaScript to the page to see what would happen.

    The first part you'd have to tackle is getting all the Roles that the user is associated with and determining if any of those Roles are appicable to this workflow. I believe that the TS_SECURITYCONTROLS table is where you might start looking.

    Also you might try simple MashupScript using the $SCRIPT() tag to see if you can control the form in the way you want.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, January 11 2011, 11:19 AM - #Permalink
    0
    Can't you just use the privlege section to define which field can be edited by whom, and then still have a custom form with 6+ tabs? With those concepts separated in SBM you can move a field to wherver, yet still have it behave as if it was a sytem field or manager field, etc.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, January 12 2011, 02:31 AM - #Permalink
    0
    I use roles in a number of workflows in Mashups. We utilize this to show/hide transitiions. I am not aware of a means to use ROLES to control specific fields. With Mashups2009, you have the power of java scripting that will enable you to show and hide fields in a transition. Using that scripting power you can manage who updates what fields based on a single selection field value. Hope this helps.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, January 12 2011, 05:00 AM - #Permalink
    0
    As far as I can tell, 2009R2 is still limited to the pre-defined sections. The dbSchema says that the constant TS_TBLID_SECTIONS in TS_TABLES is "not currently used". I'm already using Advanced and Manager sections for other role-based privilege. I still have 11 roles each of which is allowed access to their own data. Can I create extra Privilege Sections?
    Another option I'm considering would be to use sub-task / child tickets to control access.
    The reply is currently minimized Show
  • Accepted Answer

    Jeff Malin
    Jeff Malin
    Offline
    Tuesday, January 18 2011, 11:47 AM - #Permalink
    0
    Keep in mind if you are using JavaScripting that the users will still be able to see the value of those fields if they do a "View Source" on the page, because the data will be there in the HTML, just hidden on the form. Depending on the sensitivity of the data and the sophistication of your users that may or may not matter. But in general I would push back on these requirements and see if there is any way to simplify them to be able to use sections, because you're still going to hit a brick wall on restricting reporting otherwise.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 20 2011, 09:27 AM - #Permalink
    0
    Status:
    This is a more "interesting" problem that I first guessed. My current solution isn't working yet, but I feel that it's close.
    Both Javascript and Mashup script must be used. The "$SCRIPT()" tag doesn't work outside of templates. The Javascript is included in my State form. It is using XmlHttpRequest to activate the MashupScript via a URL context. This is basically "AJAX" technology for you non-webbies. On the client (Javascript) side I use the Mashups Javascript API "GetFieldValue" to get the Issue ID (with prefix) and Project name. I pass these, along with the desired Group and/or Role names and the Tab name in the URL. The Project name is required because Roles are project-specific. The Tab name is required so that the MashupScript can eventually return some contextual info back to the Javascript client. The Mashup script (running in URL context) has Shell.User, so it can lookup the User ID and determine if the current user is a member of the specified Group(s) or has the specified Role(s). It formats and returns a simple "tab=X&Auth=yes/or/no" answer using Ext.WriteStream(). The async Javascript code captures this, parses it, and does a "HideSection" using the specified tab identifier (originally passed from Javascript).
    Whew! What a merry-go-round. I'll post status as I continue.
    The reply is currently minimized Show
  • Accepted Answer

    Jeff Malin
    Jeff Malin
    Offline
    Thursday, January 20 2011, 09:48 AM - #Permalink
    0
    You're definitely doing this the same way I would (MashupScript + JavaScript), the only thing I would add is that if the ability to "View Source" is a concern, you could go further than just hide/show sections and actually render an essentially blank form, then pass the actual entitled data fields back using AJAX. But if that's not a concern than this sounds like a great way to go.
    Also it's probably not a big deal if you are just passing the Auto=yes/no but if you start trying to pass real valid XML out of the MashupScript, you may run into problems if you're doing ext.writeStreams in the script because everything comes out with text/html as the header. In that case, the function below might prove useful to you, it's what I use to send real XML out of MashupScript, with correct headers:
    function writeResponse(XML)
    dim Response
    Response = "HTTP/1.1 200 OK" & vbcrlf
    Response = Response & "Date: " & now & vbcrlf
    Response = Response & "Server: Microsoft-IIS/6.0" & vbcrlf
    Response = Response & "Expires: 0" & vbcrlf
    Response = Response & "Connection: close" & vbcrlf
    Response = Response & "Content-Type: text/xml; charset=UTF-8" & vbcrlf
    XML = "" & vbcrlf & XML
    shell.redirectHTTP = Response & vbcrlf & XML
    end function
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, January 23 2011, 09:33 AM - #Permalink
    0
    I think this is mostly keeping the average user from modifying something.
    I'll try to remember that detail about the default return format from Ext.WriteStream -- good to know!
    The reply is currently minimized Show
Your Reply

Recent Tweets