company wide (unchangeable) dashboard and preselected columns list

[schirrms]

Hi,

As the iTop CMBD usage grows, some new questions arise (and that is good).

It would be useful to be able to create some company wide dashboard (better in read-only mode). I found a interresting topic on building additional dashboard, but it seems that the dashboard can be edited by the final user. This is a good idea, but in case of an update of the dashboard, people with customized dash won't see it.
I can imagine to suppress the old dashboard and create a new one but I'm affraid that the customization would stay in the database...

Also, saying that, in my Dashboard, I plan to display a specific list of CI, maybe CI with obsoleted OS, for example. In this table, I want to set a different set of columns that the default column set.
Saying : if I display a new table with a very specific selection of Virtual Machine, I still will have my table layout coming from the <list> section of Virtual Machine, and this default column layout may not be adequate for this specific usage.
In that situation, I'm OK with the fact that some users will alter the (new) colum layout to suits their needs. But is there a way to have another default layout specific to one 'view' ? (I'm not sure that my babeling is understandable...)</list>

Thanks,

Pascal

[Jeffrey Bostoen]

You probably have the dashboard on a separate page?

I saw this, but it only sees to apply to AttributeDashboard though:

<is_user_editable>true</is_user_editable>   

optional Set to "true" to let users edit the dashboard. Defaults to 'true'

[schirrms]

Hi jeffrey,

Thanks for your feedback. In fact, I went trough this tutorial :
Add a Dashboard on a Team and in this example, I saw the same flag as you. unfortunately, true or false doesn't change anything.

Thanks,

Pascal

[schirrms]

Hi, long time ago... But, in fact, the flag

<is_user_editable>false</is_user_editable>  

does indeed prevent the dashboard modification... for non admin user !

Some 'greping' in the source code gave me this information:

$bCanEdit = UserRights::IsAdministrator() || $oAttDef->IsUserEditable();

As I tend to test my extensions as an admin, I didn't see that :)

Thanks,

Pascal

[Vincent @ Combodo]

There has been a PR to support definition of custom zlist to be used for different purpose
https://github.com/Combodo/iTop/pull/389
For now I don't think that a dashlet List can specify a zlist to use, nor specifying locally the fields to display. Maybe one day, if we haven't anything else more useful.

As you guessed it cannot prevent the user to configure the displayed fields in the list.

For the Dashboard menu which could be prevented from being modified by the User, since it was expensive and that it is always possible for any User to switch between the official dashboard version and his own version without loosing his own, we are not planning to change this.

[schirrms]

Hi again,

Still working (not Full Time) on dashboard, and following this tutorial
https://www.itophub.io/wiki/page?id=latest:customization:add-dashboard-attribute
I was able to obtain an read only (for non admin user) Dashboard
In this tutorial, the Dashboard is a xsi:type="AttributeDashboard"

But my original idea was to create a 'Company Dashboard' Menu. So I moved my Dashboard in the menu, and in this case, the type is : xsi:type="DashboardMenuNode"

And as depicted in the iTop XML reference, attributes are very diifferent between this two classes.

And, at least from what I saw during my test, the <is_user_editable>false</is_user_editable> doesn't seems to be of any use in DashboardMenuNode.

(By the way, I'm surprised to see so much difference, in my opinion DashboardMenuNode should just launch AttributeDashboard)

Is that just my (mis)understanding, or are 'Menu Dashboard' always editables ?

Any way to change this behavior ?

Thanks,

Pascal

[Vincent @ Combodo]

They are different,
1. You saw one technical difference (there was quite a high cost to control edition by User of a DashboardMenuNode, so it was never implemented, so they are always editable)
2. The other one, is the use of the :this->xxx placeholders in dashlet OQL queries which is ONLY available within an AttributeDashboard, as within a menu there no current object.

Historically speaking AttributeDashboard was created years after the DashboardMenuNode, as a quick win to greatly improve reporting capabilities even without selection/filtering options on the Dashboard. But we have not abandoned the idea (of selection/filtering options on the Dashboard), it's just not the priority yet...

[schirrms]

Thanks for the explanation, Vincent.

I'll work with that :)