How to set which folders show in the list in InfoAssist when "File" is selected to create a permanent hold file.

[Debra Waybright]

I can't seem to remember where this setting is. We've created a new folder where we want users to save their permanent hold files but I can't get it to show. I click on the File button and get a window where I can select a folder and I can type in my file name. But how do I add the new folder to that list?Thanks,

Deb

[David Beagan]

I found that adding it to the application path seemed to work. You can do this on the Reporting Server Console.

[Debra Waybright]

That was what I expected, but it didn't work. We even rebooted the server after adding it to the application path in case it needed a "kick start".

[David Beagan]

Yea, when I tried it, I only had to start creating a new report and the new folder showed up in InfoAssist. When you do APP SHOWPATH in a fex, your new folder shows up on the list?

[Debra Waybright]

Yes, it is on the list. I checked privileges, too, and those are set correctly. It's a puzzle.

[Guest]

Hey Deb

What folders do you see when you click on the file button? Just wondering how it's set up for you now.

I have an idea for you - making a group profile might be a solution.

I don't have time to go into tons of detail at the moment but maybe I can give you the highlights:

Look in your edaprint.log and search for a line that has 'u=' in it along with your user ID (or one of your users).

The g= on that line will list groups that you (or your user) belong to.

copy that g= name so you can use it for a filename. You'll be making a groupname.prf.

You know your app folders are under ibiapps? Instead go to ibiprofiles.

Open an editor and type in

APP PREPENDPATH folderyouwanttosee

Save it as groupname.prf

Next time that user logs in, theoretically the group profile will get triggered and the folder you want to see will be in the users app path.

Oh - another step I think - you'll want to go into the WFRS console and go to Access Control. In there, right click on the Basic User and choose Register Group

 

Once you create the group on the WFRS, you can also manipulate the directory/folder privileges (to make sure they can write there for example). I can't remember whether the WFRS is super picky about case sensitivity on the group name. Maybe it is - maybe not. I think the case sensitivity DOES matter in your filename (groupname.fex).

Thats just one idea.

I have to step out for a bit. I presume there's more documentation on this in the reporting server manual. I'd try to avoid having to create user ID's for every user.

This might be overkill too. Maybe you can just give Basic user more permissions to write to folders without bothering with a Group Profile.

I should have started with that idea. On the same line in edaprint.log where you see g= and u=, you'll also see an r=USR (perhaps it's USR). That's the Role. If everyone comes in as r=USR, that's Basic User. Your user ID might show up as r=SVR (server admin).

 

That'll give you food for thought. Gotta go. I'll check in later.

Toby

[Debra Waybright]

I was starting to wonder if I needed to do the register group thing. I will give this a try and see if that gets us where we need to be. Thanks!

[David Beagan]

I almost forgot, individual MR Domains or Workspaces can have the "Assign Applicaiton Path" checkmarked. This overrides the App Path setting.

[Debra Waybright]

This is just a puzzling thing to me. I created the group profile, and that makes the folder appear for our users - but not for the admins??? Even though we also have that same group membership. Does having the admin override other groups?

[Guest]

You may not be a member of the group on the client side in Security Center. But - you will be able execute code and so forth because you are 'overpermitted' on on the content iniside the repository but the file folders are Outside the repository under the reporting servers control. So the concept of overpermitted isn't there on the WFRS unless you set it up to behave similarly.

The key question to ask yourself is what groups does the WFRS think I belong to? For that - look in the edaprint.log and find your user id on a line that has the u=yourid but mainly pay attention to the g= list of groups that security center sent to the WFRS. Those are the groups that the WFRS is looking for to dynamically assign the paths.

You make just want to make yourself an administrators.prf profile and put your APP PATH commands in there. This means you're duplicating your path settings (one profile for users and one for you) but it gives you a little flexibility too (where you might be able to test a new profile setting without bothering the users).

Also, I wonder if it would help any to use the APP PATH properties of your Domain in the client as David mentioned? Maybe that'll cut out having to do so much work on the WFRS.

[Debra Waybright]

I made sure to use the g= group we are all members of. That's why I'm so puzzled. We have one Workspace that is used for companywide portals and reports, so all our in-house users get that group assigned, including the admins. And I was sure to create the prf file using that g= name. The folder is in the APP PATH in the edasprof.prf, it is in the list when I do a SHOW PATH, and everyone can see it in the Application Folders listing. The only place it isn't showing now is in the folders list for saving a file from IA for admins! 😅

[Debra Waybright]

Since none of this is working quite right, I've opened a case and will update this thread when I have a solution.

[Debra Waybright]

I think I figured out how to fix this -- submit a case and it magically fixes! 😂

I went into IA to take screen shots to attach to the case, and wouldn't you know it, there's the folder. 😵