A client called in stating his users in the ASO database had “READ” filters set to them, and yet, were able to write to the database. They had filters that were updated via MAXL that gave the users NONE access to certain districts and READ access to others. The NONE worked, but the READ did not, since they were able to WRITE. I checked everything. When I say everything, I mean, I was two steps shy from the crazy train because I could not, for the life of me, figure out what was causing the WRITE filter. I then decided to look on Oracle’s Knowledge base, and found this:
Essbase Filter Does Not Prohibit Write Access, Users Able to Submit Data to Intersections Secured with Filter as “Read-Only” (Doc ID 1916163.1)
A glorious undocumented bug. If you are pre-220.127.116.11.500, the workaround is to remove/comment out the SSOPTIMIZEDGRIDPROCESSING TRUE setting from the essbase.cfg file. After removing/commenting out this setting, be sure to restart our Essbase services for it to take affect. The TRUE fix is to install the 18.104.22.168.500 patch.
Saved another day from a trip on the crazy train!