Content Block Access for Dashboard Creators

[Ed Shooshanian1]

Today our sys admins block access to content block creation and consider the creation to be an enhancement which would go thru our dev/test/prod release cycle.

How do we add notes or even titles to dashboard so we can provide some real-time context or just improve the presentation.  For example, I might want to add a note to a dashboard explaining - how we will be working on improving this KPI over the next several months.  I would not want to have a developer create this as it's just a temporary note.  I've tried the sticky note but that didn't work well.  Is there a standard way to annotate a dashboard without a developer? 

[Thomas_Davis · Accepted solution]

Maybe you could talk with your Admin about adding some other Roles to the ACLs of the content_block_static, to open it up a bit for others to add them. Perhaps something like this:



Then you could add the report_creator, pa_pwer_user, content_admin (or whatever roles you want). That would give the Roles that already have access to creation to be the only ones that can put Content Blocks on the dashboards.  This is a conversation that you could have with your Admins, I will continue to look for other methods, based on this saying no.

[Alec Hanson]

That is a good option Thomas as Static content should be safe enough.

Another possibility is to get a Detail content block linking to a KB Article added onto the dashboard and then you can manage the content via the KB Article

[Tushar Hirpurk1]

Hi ED,

You need to deal with the Content Blocks, in that you need to used new Static HTML. 

a "Static HTML block" displays content that does not change and is the same on every page view, such as a page's welcome text or a section of formatted content. It displays the same information for all users, in all contexts.

1} Add Widget as Content Blocks

\

 2} Select New Static HTML

3}Add New Static HTML and Configure it

4} Give the name, and optional values as you want like frame, category

 5}  Select the image/logo you want to upload on dashboard

6} Configure the image  Layout/ Alignment. 

7} Save it.

Please mark reply as Correct/Helpful, if applicable. Thanks!

Regards,

Tushar

[JosephW1]

You could do the following if your admins are concerned about safeguarding the OOTB/content_admin/admin created content blocks from being edited by these newly invited individuals.

1) Create a new role 'content_dashboards' and assign it only to the intended users. Do not give this to admins or content_admins.

2) Create the ACLs for the types of content blocks these users will have access to and attach the content_admin role and our new content_dashboards role to them. This will require a combination of create/read/write ACLs for the following tables:

• Detailed content [content_block_detail]
• Flash Movie [content_block_flash]
• Header [content_block_header]
• IFrames [content_block_iframe]
• List of Content [[content_block_lists]
• Navigation Menu [content_block_menu]
• Dynamic Content [content_block_programmatic]
• Sized Content [[content_block_sized]
• Static Content [content_block_static]

  Note: some tables appear to require only plain ACLs but some require plain + * ACLs.
  Example: In my testing, Static Content only required 3 plain ACLs [create/read/write], but Iframes required 3 plain ACLs [create/read/write] + 2 * ACLs [read/write].

3) Create the following Script Include:
If you use gs.getUserByID(current.sys_created_by).hasRole() it returns wonky results. hasRole() returns true by default for any user with the admin role, so this would result in our users being able to edit admin created objects. That's not exactly what we are trying to achieve in my example, lol.

function hasRoleExactly(user_id,role) {
	var rol = new GlideRecord('sys_user_role');
	rol.addQuery('name', 'IN', role);
	rol.query();
	if (rol.next()) {
		var hasRole = new GlideRecord('sys_user_has_role');
		hasRole.addQuery('user.user_name', user_id); //UserID
		hasRole.addQuery('role', rol.sys_id);
		hasRole.query();
		if (hasRole.next()) {
			return true;
		} else {
			return false;
		}
	}
	return false;
}

   Note: In calling this script you pass it two variables: a userID (oddly enough, that field is labeled UserID but named user_name) & a list of roles. It will return false if the user lacks any of the roles. The user must have all the roles for it to return true.
   Ex:"hasRoleExactly('beth.anglin','report_admin,dashboard_admin')" 

4) Attach the following script to the write, and possibly also the read, ACLs by checking the Advanced tickbox:

if(hasRoleExactly(gs.getUserName(),'content_dashboards')){ //additional restraint for content_dashboards users
	if(hasRoleExactly(current.sys_created_by,'content_dashboards') || current.sys_created_by == ""){ //limit to their own objects
		answer=true;}
	else{
		answer= false;}
	}
else{answer=true;}

This will make it so that the new users will only be able to edit objects that were created by a user that has our new content_dashboards role, thereby safeguarding the OOTB/content/admin/other content blocks from undesired modifications. I hope this has been helpful. Please comment if you have an improvement on my method. Thanks!

The content_admin role fulfills 111 ACLs OOTB in my PDI. If we give our users static and iframe content access then we are only granting 8 ACLs, an 92% reduction. 92%! Furthermore, since the ACLs are conditional and basically restricting them from 90% of the objects on the 2 tables we are granting them, would you call that granting them 1% now? 100% * 10% * 10% = 1%
This could be a good least-possible permission method. A great part is that it still allows these new users to collaborate by having read/write privileges to the objects created by other content_dashboard  users. This can be a facilitator of teamwork.