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.