nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Make options in header 'admin-only' in Alfresco 4.2d

ebogaard

In 4.2c and older, I was able to make Header (sub)items admin-only by enclosing items between <#if user.isAdmin> and </#if>.
For example the Create Site-option was editable like that in: tomcat/webapps/share/WEB-INF/classes/alfresco/site-webscripts/org/alfresco/modules/header/sites.get.html.ftl

Also, to make the Repository button admin-accessible only, you could set "permission=admin" to the right option in: tomcat/webapps/share/WEB-INF/classes/alfresco/share-config.xml

In 4.2d, these don't work anymore and I can't find where I can influence this behaviour.
Setting <legacy-mode-enabled> to 'true', which should make the pre-4.2d way work again, but this made things far worse: the Header bar layout was all wrong.

Hope someone can point me in te right direction!

Find more posts tagged with

Comments

ddraper

The header bar has been re-written for 4.2d using a new approach that we're going to be using throughout Share going forwards. It is still possible to remove the "Repository" link from the header bar using the following configuration.

<config evaluator="string-compare" condition="RepositoryLibrary" replace="true">
   <visible>false</visible>
</config>
‍‍‍‍‍

…it should be noted that even if the Repository link is removed, it is still accessible via a direct URL and all users (by default) do have read access to Company Home.

There is also a legacy mode configuration element for building the new header using the old configuration (although as you've pointed out the layout isn't ideal primarily because of the way in which the "Sites" drop-down menu was written using custom JavaScript).

However, the new header menu should be more flexible although perhaps not in your specific example of just wanting to make certain menu items admin only through pure configuration. You can now reconfigure the menu bar via extensions where you identify the widget for each menu item, menu group, menu drop-down or menu bar (and indeed any other widget in the header) and either update it, remove it or add to it. This should make it very easy to customise the menu bar in a way that makes it more resistant to core changes.

Hopefully you won't find making these changes to arduous although I can see in this case it is probably going to be more work than it was before (and I'm sorry that this is the case) but hopefully you'll be able to see the benefits in the approach we've taken. We're already "eating our own dog food" in this regard as we take the same approach in customizing the header menu for our cloud offering.

If you have any issues customizing the header bar then please post to the forums and I'll try to help you with the solution.

Regards,
Dave

ebogaard

Dave, thanks for your response. That gives a little more insight.
What would really help, is something like an example or some pointers how to edit/modify one of these menu drop-downs (or are it groups?) and replace the original one with it (as I understand that's how it should be done now), using the web-extensions folder.

As I'm not really sure where to look for the new files that are used by the new header, I hope you can help with that as well.
And also: it would be rally nice to be able to hide the Repository and Create Site links for non-admins, but show it for admins. Not completely remove them. I know what URL to use, but probably not all admins in the world do 😉

Also, in "tomcat/webapps/share/WEB-INF/classes/alfresco/site-webscripts/org/alfresco/modules/header/sites.get.html.ftl" I see things like <#if showCreateSite> and <#if showFindSites>. This is what I'd normally use to add an admin-only check. How/where can you configure these switches?

ddraper

You're right that I need to get some examples together and I'm hoping to get some blogs done soon but things are a little busy as we're working hard to close out the 4.2 Enterprise release at the moment. You should be able to piece together the information you need for some of my earlier blogs. Effectively what you need to do is build an extension module that targets the "share-header.get" WebScript and create a JavaScript controller extension (http://blogs.alfresco.com/wp/developer/2011/08/05/customizing-alfresco-share-javascript-controllers/) and use the "widgetUtils.findObject" helper function to locate the widget you want to work with and then either add/remove/modify menu items.

The share-header.get WebScript uses the "share-header.lib.js" file to build the header which you could import and use to build a completely new header if you wanted to completely replace the default "share-header.get" WebScript via the web-extensions folder.

FYI… setting the "visible" element to "false" will only hide the Repository link for non-Admins (which is what you want)… it should actually be like that by default and I've actually committed that fix this morning.

Regards,
Dave

ebogaard

Dave, thanks for the additional info.
As I read it, it should be easy to hide the Repository-button for non-admins.
To hide the 'Create Site'-button for non-admins: if I find the time to have a good look at this, I think I can fix myself some extensions/replacements for the Share header.

Regards,
Erwin

ddraper

You've picked the one part of the header menu that is slightly more complicated to customize! 😉

Basically you have to do the following:
1) Create an extension the "share-header.get.js" WebScript JavaScript controller
2) Create a new widget that extends "alfresco/header/AlfSitesMenu"
3) Make the new widget override the "addUsefulGroup" function so that the create site menu item doesn't get added
4) In your extension controller use widgetUtils.findObject to locate the "HEADER_SITES_MENU" widget
5) Modify the definition so that the "name" attribute is set to your custom widget
6) If you create your custom widget in your own package then you'll need to update the surf.xml to add the root location of your module so that it can be picked as an AMD resource.

The reason that this example is slightly more complicated (e.g. than say just finding a menu item and removing it) is because the sites menu does a lot of dynamic generation of menu items (e.g. the recent sites and favourite items). However, I can see that I should have included some boolean configuration so that you could toggle which menu items are shown (e.g. the create sites and site finder, etc). Then this would have been much easier. It's obviously too late for me to commit this change to the 4.2d Community release but I can have it in place for Enterprise and the next Community release.

Regards,
Dave

ddraper

I was a bit embarrassed by this omission so I raised https://issues.alfresco.com/jira/browse/ALF-19911 and added some configuration options to make customization easier. Obviously this isn't a lot of use for 4.2d Community but there may yet be another 4.2 community release before 4.2 Enterprise is released.

The updates mean that you can control which elements are displayed by modifying the definition for the "HEADER_SITES_MENU" widget, e.g. the JavaScript controller extension just needs to contain:

var sitesMenu = widgetUtils.findObject(model.jsonModel.widgets, "id", "HEADER_SITE_CONFIGURATION_DROPDOWN");
if (sitesMenu)
{
   sitesMenu.config.showCreateSite = user.isAdmin;
}
‍‍‍‍‍‍‍

This would result in the create site menu item only being displayed if the current user was the admin. You could do similar things for the Recent Sites group, the Useful group, the favourites controls and the site finder menu item.

Regards,
Dave

ebogaard

Hi Dave, thanks for your enthusiasm and raising a JIRA item.
Is there any way to (easily) implement your fix in 4.2d? Is there a commit # available with all the needed changes? So far, I can't find it in the public SVN.

ddraper

The commit I made was revision 54861. The public mirror now appears to be at 54900 so it might have just not caught up at the time you last looked. The path to the file that was changed is this: "/Slingshot/source/web/js/alfresco/header/AlfSitesMenu.js"

Regards,
Dave

ddraper

FYI: Managed to cobble together a first blog on customizing the header: http://blogs.alfresco.com/wp/developer/2013/09/04/customizing-the-share-header-menu-part-1/

bopolissimus

Hi Dave,

I have the opposite issue. I *want* the repository to be available to non-admin users. This is because some external WS clients access the files in the user's User Homes/${username} folder and the users want to use /share and view those files. Am I supposed to set legacy-mode-enabled to true so that non-admin users can see the Repository link?

There's no legacy-mode-enabled or header block in share-config-custom.xml.sample so I tried a few things. first copy share-config-custom.xml.sample to share-config-custom.xml

1. there's a config/flags block in share-config-custom.xml, so I added legacy-mode-enabled there with setting true. after alfresco restart, non-admins have no Repository link.
2. I copied the whole share-config.xml into share-config-custom.xml 🙂 and set legacy-mode-enabled to true in the custom file. no Repository link for non-admins after restart.
3. I edited share-config.xml and set legacy-mode-enabled true there. after restart, non-admins DO have the Repository link.

I'd much prefer to set that in custom config though. What am I missing?

Thanks for any pointers,

Gerald Quimpo

ddraper

You should just be able to set the <visible> elememt to true (see earlier comments) then it will be visible for all users (including Admin). You don't need to enable legacy mode.

Regards,
Dave

bopolissimus

thanks, that worked. It has the same issues as enabling legacy mode (Sites is lower than the other links, link text has spaces replaced by %20), but it works from shared/classes/alfresco/web-extension/share-config-custom.xml :-).

ebogaard

Hi Dave,

as 4.2.e is out, which should simplify what I initially wanted, I checked your blogs a second time.
The objective is still the same: hiding the CreateSite-option in the Sites-menu.

First I tried to hide the option for all users. So I created the following files:
tomcat/shared/classes/alfresco/web-extension/site-data/extensions/share-header-extensions.xml

<extension>
   <modules>
      <module>
         <id>Hide Create Site</id>
         <version>1.0</version>
         <customizations>
            <customization>
               <targetPackageRoot>org.alfresco.share.header</targetPackageRoot>
               <sourcePackageRoot>test.hide-create-site</sourcePackageRoot>
           </customization>
         </customizations>
      </module>
   </modules>
</extension>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

tomcat/shared/classes/alfresco/web-extension/site-webscripts/test/hide-create-site/share-header.get.js

// Find the "Sites" menu…
var sitesMenu = widgetUtils.findObject(model.jsonModel, "id", "HEADER_SITES_MENU");
if (sitesMenu != null)

{
   // Hide the site finder…
   sitesMenu.config.showCreateSite = false;
}
‍‍‍‍‍‍‍‍‍‍

Even though I followed your code examples, this doesn't hide the option for admin or non-admin users. What am I doing wrong?

Only when I set showCreateSite to false in tomcat/webapps/share/js/alfresco/header/AlfSitesMenu-min.js, the option isn't shown anymore.

ddraper

Did you download and try the sample JAR linked on http://blogs.alfresco.com/wp/developer/2013/09/16/customizing-the-share-header-part-3/ ? Although it's hiding the Site Finder (and not create site) if that works then it should be easy to adapt. I've just tried it again on my local environment and it's working for me,

Regards,
Dave

ebogaard

To be sure, I tried the JAR from your blog.
First I put it in tomcat/webapps/share/WEB-INF/lib/, but after a restart the sitefinder was stll there.
I also tried tomcat/shared/lib/ and tomcat/lib/, but without success.

The My Files link is also still there.

I'm using a fresh install of 4.2.e on Centos 6 x64 with only some small modifcations to some dashlets, but none related to the header. I use a non-admin test user.

Is there any way to check if the jar is active and the files in it are loaded succesfully?

ddraper

Can I just check that you're definitely deploying the module via the module deployment page (e.g.at share/page/modules/deploy) ?

ebogaard

Hi Dave,

thanks for your suggestion: deploying it via the module deployment page was the solution. I probably didn'd re-read part 1 of you blog, where you mention this.
And I'm not yet very used to deploying new code via that mechanism, as for a long time it has been "placing files + restart = profit".

The good news is that I also found the previous additions I made (based on your code) to hide 'Create Site'.

Thanks for your help.

ddraper

It is possible to have modules auto-deploy (see this post:http://blogs.alfresco.com/wp/developer/2012/01/04/extensibilty-updates-roundup/) but the default it for module deployment to be manual. Glad you've resolved your problems though.

Regards,
Dave

kart

Hi Dave,

First, I would like to thank you for the very useful information you provided on the Alfresco forum and on your blog.

I'm new to Alfresco, I just installed the 4.2e Community and did few modifications such as hiding the Repository link from the header menu for users that will be external to our company.

In your post of September 2nd, you wrote:
<blockquote>…it should be noted that even if the Repository link is removed, it is still accessible via a direct URL and all users (by default) do have read access to Company Home.</blockquote>

Is there a way to disable this link for a user group? For additional security, I would prefer the users that do not have access to the Repository link to not be able to manually type the URL to bypass the restriction to get access to the repository.

Thank you
Stephane

ddraper

Hi Stephane,

Just to clarify, when I say accessible via direct link… authentication is still required (an unauthenticated user wouldn't be able to view the page). Also, the user would still be restricted by their usual permissions - so in most cases they'd just be be able to read repository information (apart from nodes they do not have access to, e.g. private sites, etc). If you want to completely prevent a user from accessing the page (even via typing a URL into the browser address bar) then you'll need to modify the webapps/share/WEB-INF/classes/alfresco/site-data/pages/repository.xml to change the <authentication> setting from user to admin (this will restrict anyone without admin privileges).

Hope that helps,
Regards,
Dave

kart

Hi Dave,

Thank you very much for the quick reply and for the useful information. Since an authentication is required to access the page, then I will just set the access rights as required for all pages (or links) accessible from the repository page and this will be perfect.

Thank you again,
Stéphane