Hello,

Don't have a lot of experience with security within WF reporting, so I'm hoping this will be a fairly easy question.

Here is my current workflow:
-I have one main report with a drill-down setup sitting on a portal.
-That drill passes data and pre-populates an HTML web form.
-Users can then manually manipulate certain data fields to adjust data.
-Submitting that form then calls an SSMS stored procedure to write an event to the DB and update the corresponding data necessary.

This all works fine and dandy, but currently anybody with access to the portal page has access to make changes.

We have two AD groups setup for security, one group for view-only and one group for view/update. What is the easiest way to lock down that drill so that only the people in the "update" group have rights to it?

The following scenarios are bouncing around in my head, but I don't know how to implement them:

1. Only allow the drill to work for people in the update group therefore essentially only allowing the form to display for those that should have access.

2. If can't lock down the drill then lock down the form itself. If user is in the update group allow all fields to be editable, otherwise display the data on the form but set all fields and the submit button to be disabled. I know this would require some JavaScript, which I can handle, but this would require me to know the permission group the user belongs to and I'm unsure if that piece of data can be passed from FEX to HTML form.

Either of those solutions would work, but I'm open to other suggestions.

Any suggestions/advice/documentation links would be greatly appreciated.

Thanks,
JC

This message has been edited. Last edited by: jcannavo,

In 8.1.05 there is the &FOCSECGROUPS variable that will tell you all the groups that a user is assigned to. You could parse the values, loop through them and then create a validation flag based on whether the user has the sufficient "Update" group. The you can use conditional styling to provide the drill down functionality only for those which passed your validation.

Thanks Eric, I'll see if I can find that variable and implement it.

Seems that we don't have &FOCSECGROUPS. Via Dev Studio in the GUI I don't see it listed within system variables nor do I see it listed when I try to define. I manually tried to SET it to another variable and nothing populates into that variable. Is there a possible setting within WF that may need to be flipped to get this variable to show up?

Otherwise any other suggestions on how to validate what group a user is in?

Update, just found the following in which I'm going to review... http://forums.informationbuild...367058876#8367058876

This message has been edited. Last edited by: jcannavo,

The pre-8.0.09 way to get a users groups was GRPLIST(outputLength, outformat), although this provided you with the LDAP group associated with a user. Now the IBI "Blessed" way to get a users groups is the &FOCSECGROUPS variable. I see you found a thread discussing that variable. There is also a way to see the LDAP groups instead WebFOCUS group assignments, but you have to update the odin.cfg to do so.

This is the default setting for WebFOCUS. I would try to just create a procedure in the content area that says

 -TYPE &FOCSECGROUPS 

and see what it says.

quote:

The pre-8.0.09 way to get a users groups was GRPLIST(outputLength, outformat), although 11.2.0.2

In your WebFCOUS procedures, you can use some conditional statement I in your drilldown.
1. When user match the condition , drilldown will active.
2.1. When user does not match the condition , drilldown will In active.

Hoping this will help for this.

@Avinash- yes, thank you. I do plan on setting conditions for the drill down, but I first need to find how to get the security group data first.

@Eric- When I TYPE it out it does return the data I think I need. Weird that when I tried to SET a variable before it didn't work.

Thanks for the feedback! I'll work with it some more and report back.

I have it working now. Thanks again for all your insights! Here are the changes that pertain to this post:

I set a variable to hold the security group data

-SET &securitygroups = &FOCSECGROUPS;

In define I create a text field to set the groups into, then check to find out if that user has the admin group in their list:

thesecuritygroups/A2000='&securitygroups';
ISADMIN/I5=
IF POSIT(thesecuritygroups, 2000, 'The_Admin_Group', 32, 'I5') GT 0 THEN
1
ELSE
1;

Finally I do a NOPRINT selection of ISADMIN so that I can use it within conditional formatting of the drill field:

TABLE FILE GROUPED_DATA
PRINT
     DRILL_FIELD1
     FIELD2
     FIELD3
     FIELD4
	 FIELD5
     ISADMIN NOPRINT
ON TABLE SET PAGE NOLEAD
ON TABLE SET PAGE-NUM NOLEAD
ON TABLE NOTOTAL
ON TABLE PCHOLD FORMAT HTML
ON TABLE SET HTMLCSS ON
ON TABLE SET STYLE *
     INCLUDE = IBFS:/EDA/EDASERVE/_EDAHOME/ETC/endeflt.sty,
$
	DEFMACRO=COND0002,
     MACTYPE=RULE,
     WHEN=N5 EQ 1,
$
TYPE=DATA,
     COLUMN=N1,
     BORDER-TOP=LIGHT,
     BORDER-BOTTOM=LIGHT,
     BORDER-LEFT=LIGHT,
     BORDER-RIGHT=LIGHT,
     TARGET='_blank',
     MACRO=COND0002,
     FOCEXEC=/WFC/Repository/Portal/Hidden_Content/CodeDirectory/CallHTML.fex( \
     VARIABLE1=N2 \
     VARIABLE2=N3 \
     VARIABLE3=N4 \
     VARIABLE4=N5 \
     ),
$

Please note this is not complete code, I just took what was relevant and included it here

you could just do this in the define instead... not that what you're doing wouldn't work

 
ISADMIN/I5 = IF &FOCSECGROUPS.QUOTEDSTRING CONTAINS 'The_Admin_Group' THEN 1 ELSE 0 

Also, I think you meant your ELSE statement to be 0, not 1...

I find .QUOTEDSTRING to be cleaner then putting my own quotes around the variable. I run into less problems when I do that. Especially with _FOC_NULL and those things.

I was trying to figure out where exactly to do the "Contains", but when I found what I have currently working I just let it be. That's a great idea, thanks!

And yes, the ELSE definitely needs to be a zero. I have the zero commented out in my code beyond what I included in my post as I needed to set it to always show for a demo I'm giving as this security piece is a prototype.

Thanks again!