Colored projects on a planning report

What if you want to create a planning report where the projects have different colors like this:



And not like this:    or  

Keep in mind that table cells are formatted from left to right, first the cell on the left, then the one on the right.

First step is to remove the black cell border on the right side of each cell:

Then create a conditional formatting rule to add a matching color cell border on the left side:



The BO security model: simplicity

In this blog series I will share insights I've gathered over the years on how to setup an effective security model: simple, structured, maintainable, flexible, expandable and easy to use.
In this fourth part of the series I will focus on simplicity. As stated the goal is to create a security model that is simple and structured.

·         This blog series is aimed at experienced BO administrators, which means there will be no how-to screenshots

·         This blog series can be used as a guideline, it cannot be used as a manual

·         This blog series only covers the internal BO stuff. No windows AD or SAP roles and no IAM software

The BO security model: object names

In this blog series I will share insights I’ve gathered over the years on how to setup an effective security model: simple, structured, maintainable, flexible, expandable and easy to use.
In this third part of the series I will focus on the names of objects. As stated the goal is to create a security model that is simple and structured. The object names play a big part in this.

·         This blog series is aimed at experienced BO administrators, which means there will be no how-to screenshots

·         This blog series can be used as a guideline, it cannot be used as a manual

·         This blog series only covers the internal BO stuff. No windows AD or SAP roles and no IAM software

User types

Let’s assume there are four types of users on your systems:

• Endusers
• Analysts
• Reporters
• Designers

Where each type is an extension of the previous one, so there is some kind of structure in these types.

Per type there will be a user group and a CAL.

      

When I assign these user groups to folders it looks like this:

Although they are sorted alphabetically I don’t like that very much, So I make a little change to the user type user groups, to make use of the alphabetic sort:

After this little name change it’s much easier on the eye. And it’s making the model a bit more structured.

Organisation user groups

Lets add a department to the system, Sales. I create folders which represent the structure of the sales department and corresponding user groups. Theses folders and user groups are used to define access. Both have the same structure but the don't have the same names.

Doing this makes them appear neatly ordered when they are assigned to the folders:

Total user security on folder Sales \ EMAE \ NL now looks like this:

The BO security model: an introduction

Over the years I have seen a lot of BO security models. Probably most of them were quite nice when they were implemented. They always start out as simple and structured models and everybody is determined to keep it that way. I am sure that if there were no business users on the system it would stay that way, simple and structured. But in real life a security model evolves, new business departments join and have different needs: we don’t want everybody to be able to schedule reports. More mature BO users may come up with extra needs: we want some users to only see their own instances and others to see all instances. The system grows: we only want to see a list of our colleague’s when we sent a report not the whole world. And new functionality to BO is added, like the commentary in BO 4.2.

After some time the simple and structured model begins to turn into a big ball of mud: haphazardly structured, sprawling, sloppy, duct-tape and bailing wire: 

• complete custom access levels (CAL) are copied and then one little thingy is changed
• user groups are created with weird names and very specific functions
• users are directly assigned to folders and given advanced rights 

In this blog series I would like to share some insight I gathered over the years. These can serve as guidelines the next time you have to work on a model. 

·         This blog series is aimed at experienced BO administrators, which means there will be no how-to screenshots

·         This blog series can be used as a guideline, it cannot be used as a manual

·         This blog series only covers the internal BO stuff. No windows AD or SAP roles and no IAM software

When I’m implementing a new security model I want it to be effective. Where effective stands for: simple and structured. But also maintainable, flexible, expandable and easy to use.

Simple, structured, maintainable, flexible, expandable and easy to use. That’s a lot! Well actually they are interrelated, if you give it structure and keep it simple it will be easy to use and maintain. And if you’re lucky it turns out to be flexible and expandable as well. 

I never re-use any of the existing CALs because I don’t want to mess with the existing model. When you create new CALs you can run both models on the same system for comparison and testing. And reverting to the original model in case of issues is easy, just delete all the new CALs.

I prefer to create the new model on a sandbox machine and when it’s finished and tested, promote it to a live system. Start with development, then test, UAT and production. When issues are found resolve them, go back to the sandbox, make the same adjustments to your model and start promoting again.

If a model is a mess, don’t recreate the mess in a structured way. If a model is a mess manage expectations and preach that the new model will not be exactly like the old one.

A BO security model consists of: 

• access rights (view, edit, delete etc.) 
• users 
• objects (reports, universes, connections etc.) 
• assignments: the relations between them 

There are hundreds of access rights, they will be grouped in custom access levels (CALs).
There can be hundreds of objects, they will be grouped in folders.
There can be hundreds of users, they will be grouped in user groups

In the assignments I will only use these grouped items: folders, user groups and CALs.

It is a humongous mistake maybe even a mortal sin to assign directly on an object ! Even if it is only once ! Exception: Calendars don’t have a folder structure, if you want Calendars to not be visible to everybody you should grant access on object level.

In the next blog I will talk about the structure of the model from a very high level.

Lean WebI customization

In 4.1 there is this new feature to customise the Web Intelligence interface. It's a nice feature, but can it be useful? Yes it can, well at least I think so.

When this feature is combined with opendocument there is a huge visual impact. And this can be very useful, especially when the opendocument link comes from outside of BO, for example a sharepoint portal. Changes are that the business user clicking this report link doesn't know anything about BO Web Intelligence.

The 'standard' opendocument view is something like this

But realizing that the business user knows nothing about Web Intelligence, there is a lot of visual noise and cluttering on this screen. Lets make some customization and remove all the Web Intelligence stuff to make it lean.

I created an extra usergroup in BO and assigned the business user to this group. For this usergroup I set the customization:

Now the 'lean' opendocument view is presented:

This is much better!

Starting with BI Workspaces

Workspaces are a unknown part of the BusinessObjects environment and maybe also an underestimated part, Workspaces are created in the BI Launchpad. They can be used as landing page or they can be opened from the launchpad manually.
What I am going to show here is how to build a very simple workspace with templates.
Open the workspace editor using the Application menu in the BI Launchpad.

Click the layout dropdown box and change to Freeform.

On an empty workspace drag in a navigation list component.

Edit it using the wrench symbol in the top right corner and select 2 webi report. Or drag and drop 2 webi reports on the navigation list.

There it is, it’s done. Your first workspace. Now you can save it and execute it from the BI Launchpad. You do not have to save it, exiting edit mode gives you a change to test the new workspace.

When you click 1 of the reports on the navigation list, by default, the report runs it the total workspace window. Click the square symbol on the left side to return to the navigation list.

And when the other report is clicked:

If you want to run the webi report in a part of the workspace window, you need to drag in a viewer component.  No configuration is needed, the are connected automatically.

Click one of the reports:

And click the other report:

If there are multiple navigation lists and multiple viewers on the workspace some configuration is needed.

I named the viewers top and bottom (using the edit / wrench of the viewers).

Then I connected each navigation list to a specific viewer. (using the edit / wrench of the navigation lists).