One of the great features of FX is the ability to restrict financial report access to the user's assigned departments. This assignment is done by user SYS in the Financial Reporter by right-clicking on any department in the View | Departments list, and selecting "Edit user departmental restrictions", then ticking the appropriate boxes.

When assigning departments to a user, the individual departments and departmental ranges both show up to be ticked. However, it turns out that ticking a departmental range does nothing; the individual departments must be ticked in order to assign departments to a user.

There are two possibilities here - either Softrak intended to allow assigning at the individual departmental only, and the departmental ranges should not be displayed on the list, or Softrak intended to allow assigning at the departmental range level, and it is not working properly.

I'm hoping it's the latter, and that Softrak will get it working properly, because maintaining the departmental restrictions at an individual level can become a very tedious process when there are lots of users and departments.

But if it's the former, please remove the bogus departmental ranges from the list to avoid confusion.

This might apply to Ledger as well - I have not tested it out.

Thanks

Steve

Hi Steve,

This is working for me in my simple test in the sample data. But there is a question here:

If you grant a user access to a range of accounts, but not access to one of the accounts that makes up that range, what is your expectation of the behavior? In my test I gave a user access to 100:150, but not to either 100 or 150 as individual departments. I also tested with a wildcard mask ("?50") and a list ("100;150;200"). The ranges selected were the only items in the department drop down selection for the user. The individual departments do not show up unless they are also ticked.

My expectation is that every item you check as permitted for a user would show up in the drop down. What are you experiencing?

My expectation is that when you tick an item, whether it's an individual department or a departmental range, the user is granted full access to that department or range. In other words, each item stands on its own.

If it is mandatory that each individual department within a range be ticked for the user to be granted full access to the departmental range, then why bother offering the departmental range box as an option to tick. Ticking it or not ticking it makes no difference. It should show up on the dropdown list only if all of the departments in the range are ticked.

Your scenario is the exact issue that resulted in my posting. A client added a new department and it wasn't showing up in the departmental range report. They didn't expect that they would have to tick the individual department, because the departmental range was already ticked.

Steve

Hi Steve,

That's exactly the way the department selection drop down is working, so what are are you referring to?

Hi Andrew,

Reread Steve's last paragraph. I think you're saying the same thing except that Steve is pointing out that when a department is added within the previously selected range, it doesn't show that new department in the totals.

Just like the .Range command on the statement, a departmental range should include any newly created departments that fall within that range.

You may have to hit the Refresh button, or have ".AutoUpdate" in cell A2. If the department is in the range, then it will be included in the figures. If it isn't being included, then there is something other than security likely causing the problem.

Hi Steve,

I confirmed after my last post that when adding department 225 to the sample data and doing a new retrieve, a previous user restriction allowing the range 200:250 includes the entry I made to department 225 in the report. So it works for me.

Hopefully I interpreted your comments correctly.

Well it doesn't work for me, nor for my client. And of course I am Refreshing.

In the sample data, set up a test user ZZZ and give them access to dept 100 and dept range 100:150, but don't give them access to dept 150.

Then launch the statement AF!DepartmentSummary.SAM and expand it. As user SYS, you will see departments 100 and 150, but as user ZZZ you will see only dept 100, even though they have access to the dept range itself which includes dept 150. That's just not right!

To repeat from above, giving user ZZZ rights to the dept range has no effect. It should either work properly (giving the user access to all of the departments in the range) or the dept range should not appear as an option for granting access and should only be available from the dropdown list if the user has access to all of the individual departments in the range. I'm hoping it will be the former.

Steve

Hi Steve,

Thanks for the detailed series of steps to re-create what you are seeing. Your first post does not mention the "DepartmentSummary" financial statement or the "RangeDept" SmartSheet command, so Dan and I both started with different statements that do not exhibit a problem. Bugs are always obvious when you find them (and know how to create them).

The actual problem is:

But the programmer can argue that the program is working as they expected, since access has not been granted to the individual department numbers, only the summary total (and in the DepartmentSummary statement, the summary total is correctly calculated and displayed).

Perhaps the correct method of changing the program so it works the way you and your client would prefer, would be to automatically enable all the individual departments when a department range, wildcard or list is chosen. The next question would be, if you deselect an individual department, does the program need to scan all the ranges and disable all the ranges that include the department to be hidden?

For consistency (especially so you don't see the kind of problem you describe here), I think the answer has to be "yes". However, this means that it will become impossible to get the kind of result you see now - where a user is allowed to see a summary total, but not the department details that go into that total. That might be a desirable thing at some sites.


This also raises a question when a new department is added. If the new department is in a range, should it be automatically enabled? The argument would be "No" - the range should be disabled - to ensure the security is set the way the user desires (and to be consistent with the security handling elsewhere in Adagio).

So, in the interim, while these decisions are decided and implemented, your client will need to enable the individual departments if they want the user to be able to see the individual departments on expansion of "RangeDept".

I'll get R&D involved in this discussion.

Thanks for bringing this to our attention and I apologize for the long reply.

I too was originally looking at an income statement without the rangedept command. So I saw the balances of the accounts change when I selected the department range. What I didn't test was the drill down. So now I see that the drill down does not show the details of the dept that isn't ticked.

Sorry for the confusion Steve.

Dan - do you have any feedback on how the program should behave in this case?

I would agree with Steve that if you grant a user permission to a range of departments, you want them to see all the departments including the details. It would be consistent with the behavior of ranges throughout the Financial Reporter and like Steve said, makes managing access to numerous departments much easier.

As for your comments:



I agree with the first sentence, but I'm not so sure the answer to your second sentence/question is "yes". Because as you pointed out, the ability to see a summarized total without details of certain departments might be desirable.

I think Lyndon and Ken would be good people to ping on this question. I think they both use FX with departmental restrictions and I venture to say this could have a big impact on their clients one way or another. Although, the needs in First Nations tend to focus on individual programs so perhaps the range issue would not be such a concern.

It's very complicated. The program cannot tell the difference when it "wakes up" between a department that the user is not allowed to see, and a department that has been added since the last time it was launched.

The more I have been thinking about this, the more I think the program is doing exactly what it has been asked to do.It is correctly displaying the summary amounts and hiding the details unless specifically told that this is OK.

In Adagio, when you add a new menu item or security controlled feature, the item is disabled for everyone until it is explicitly turned on. I think that has to remain the way it works. Otherwise users may be given access to functions you want to keep private.

But this also means that you have to edit the specs, every time you add a department to your chart - hardly optimal.

Normally when there is this kind of implementation dilemma you resolve the problem with an "option" and let the user decide how it should work. But in this case I think the desired behaviour will change at a single site, depending on the circumstance at the time.

Another approach for the interim would be to dispense with the user department restrictions in FX and set up automated retrieves into separate databases for the individuals involved that only retrieve the departments they are allowed to see. Then you don't have to worry about restrictions in their data since it will only contain departments they are authorized to inspect.

Hi Andrew

Sorry I didn't mention the spec I was using. I didn't think it mattered. I used it because it highlighted the problem most clearly, little did I know that it was the only type of spec that exhibited the problem.

Automated retrieves into separate databases is a non-starter. My client has 20 department managers who use FX. The thought of managing the automation, including managing 20 different databases and shortcuts, is too painful to consider.

I agree with you that the program is doing exactly what it has been asked to do. However, the result is unsatisfactory and confusing.

I will try again.... If the program is not going to allow ALL of the departments within a departmental range to be displayed on a financial statement, because at least one individual department within the range is not ticked, then please don't show departmental ranges on the user departmental restriction list, since ticking those has no effect. I would rather that not be the case, and that departmental range ticking takes precedence over individual department ticking (including new departments), but I can live with it either way.

Departmental ranges should only be available for selection when displaying a financial statement if all of the departments within the range are allowed and the report will display properly. I can't live with having to explain reports not displaying properly.

Steve

Hi Steve,

I think you'd be trading one explanation for another, since the addition of a new department would cause all the account ranges that include the new department to "disappear" when the manager opened their financial statements until SYS added them all back.

Another approach would be to display a message on drill down or Expand of "RangeDept" with something to the effect that:

Perhaps there is also some tool we could provide for SYS which would make it easy (easier) to update the ranges and individual departments in user security.

Both good approaches.

You are correct about trading explanations.

Steve

If nothing else - you can point them at this long (and wordy) thread to explain the complexity.

HI Steve,

I only use separate databases when rolling out Fx to managers and have a number of clients that approach the 20 database separation. Brian Stief provided me with a structure many years ago that I have used and adapted over time. I do not want managers accessing the same database as I believe that there are problems with multiple uses in the same
financial reporter modules whether that is in FX or GL (I could be wrong as this may have been fixed a few upgrades ago). Once setup the management of 20 or more databases is not a big deal. I think Brian has clients with many more datasets that 20 being updated on a nightly basis.

We used to run into problems updating databases when users did not log off their FX session and held the files open causing the retrieve process to fail and hang (ultimately consuming lanpaks). Russel Harder who works with my client base as well as his own, came up with the idea of having a second "update" database for each "live" fx database. What we do is do the retrieve on the "update" database and then use an xcopy to copy all the files in the "update" folder over the files in the "live" folder. No more "hanging" FX retrieve processes and clean data retrieves each night.

For my and my client base, who often have non-sequential department numbers being brought into a specific dataset, the management of department security is far too cumbersome and prone to mistakes.

If you would like to discuss this further, give me a call.