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; } } }

TS6 custom menus - role restrictions

Adam Stoller

I'm trying to follow the documentation (bits and pieces here and there) - and I modified the ui_custom.xml and roles_custom.xml files in the customer_src/ directory structure - run 'make.sh' to copy them into the customer/ directory structure and then run install_webapps.ipl -f -i to rebuild the web applications to try and get the changes reflected in the UI.

My ui_custom.xml looks something like this:

<iwov-ui>
 <action-list id="iw.ccpro.filesys.menubar">
  <menu id="iw.ccpro.file.menu">
   <separator id="iw.ccpro.file_menu_4.separator"/>
   <link id="cu.viewTouch.link"     operationID="cu.viewTouch.op"    .../>
   <link id="cu.changepass.link"    operationID="cu.changepass.op"   .../>
   <link id="cu.dirswitcher.link"   operationID="cu.dirswitcher.op"  .../>
   <link id="cu.metadata.link"      operationID="cu.metadata.op"     .../>
   <link id="cu.admindelete.link"   operationID="cu.admindelete.op"  .../>
   <link id="cu.adminmove.link"     operationID="cu.adminmove.op"    .../>
   <link id="cu.deletemeta.link"    operationID="cu.deletemeta.op"   .../>
   <link id="cu.metadelete.link"    operationID="cu.metadelete.op"   .../>
   <link id="cu.masschange.link"    operationID="cu.masschange.op"   .../>
   <separator id="iw.ccpro.file_menu_5.separator"/>
   <link id="cu.new_shown_env.link" operationID="cu.new_show_env.op" .../>
   <link id="cu.old_shown_env.link" operationID="cu.old_show_env.op" .../>
  </menu>
 </action-list>
</iwov-ui>

My roles_custom.xml file then looks like this:

<roles>
 <role id="author">
  <operation id="cu.admindelete.op" isPermitted="false"/>
  <operation id="cu.adminmove.op"   isPermitted="false"/>
  <operation id="cu.deletemeta.op"  isPermitted="false"/>
  <operation id="cu.metadelete.op"  isPermitted="false"/>
  <operation id="cu.masschange.op"  isPermitted="false"/>
 </role>
 <role id="editor">
  <operation id="cu.admindelete.op" isPermitted="false"/>
  <operation id="cu.adminmove.op"   isPermitted="false"/>
  <operation id="cu.deletemeta.op"  isPermitted="false"/>
  <operation id="cu.metadelete.op"  isPermitted="false"/>
  <operation id="cu.masschange.op"  isPermitted="false"/>
 </role>
 <role id="admin">
  <operation id="cu.metadelete.op"  isPermitted="false"/>
  <operation id="cu.masschange.op"  isPermitted="false"/>
 </role>
 <role id="master">
 </role>
</roles>

Authors and Editors correctly see only the first four (and last two) items, Masters correctly see everything, but for some reason Administrators seem to see only the first four (and last two) items instead of the first seven (and last two) items.

Anyone see what I'm doing wrong here - or is this a TS6 bug?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Find more posts tagged with

Comments

Adam Stoller

I still haven't figured out why Administrators see the same [lack of] menu options as Authors and Editors.
Anyone?

Also - how does one remove "standard" menu options on a per-role basis?

With the custom menu items I use the oerationID of the custom item to restrict it for a given role.
I tried using the refid of the standard menu items (e.g. "_iw.ccpro.create_simple_file.link") within the roles_custom.xml file but that didn't work.
I tried using the id of the standard menu items (e.g. "iw.ccpro.file_menu.create_simple_file.link") within the roles_custom.xml file but that didn't work either.
I could use the <iwov-delete> directive within the ui_custom.xml file - but I don't see any way to restrict the deletion based on role.

Is this functionality that was lost?
Is it coming back in 6.1?
Do I need to file a bug on this?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

PJoneja

When it comes to setting permissions, you should explicitly list permissions as either true or false for each role. The reason for this is that the way we handle permissions will be changing in the future, and therefore the assumptions that we make when loading the roles.xml files may change.

The best assumption to make is that if you specify the permissions for an operation ID for one role, you should do so for all roles. That way you won't be relying on any of our internal logic that may change in the future.

I recommend that you structure your roles files as follows:
<roles>
<role id="author">
<operation id="cu.admindelete.op" isPermitted="false"/>
<operation id="cu.adminmove.op" isPermitted="false"/>
<operation id="cu.deletemeta.op" isPermitted="false"/>
<operation id="cu.metadelete.op" isPermitted="false"/>
<operation id="cu.masschange.op" isPermitted="false"/>
</role>
<role id="editor">
<operation id="cu.admindelete.op" isPermitted="false"/>
<operation id="cu.adminmove.op" isPermitted="false"/>
<operation id="cu.deletemeta.op" isPermitted="false"/>
<operation id="cu.metadelete.op" isPermitted="false"/>
<operation id="cu.masschange.op" isPermitted="false"/>
</role>
<role id="admin">
<operation id="cu.admindelete.op" isPermitted="true"/>
<operation id="cu.adminmove.op" isPermitted="true"/>
<operation id="cu.deletemeta.op" isPermitted="true"/>
<operation id="cu.metadelete.op" isPermitted="false"/>
<operation id="cu.masschange.op" isPermitted="false"/>
</role> <role id="master">
<operation id="cu.admindelete.op" isPermitted="true"/>
<operation id="cu.adminmove.op" isPermitted="true"/>
<operation id="cu.deletemeta.op" isPermitted="true"/>
<operation id="cu.metadelete.op" isPermitted="true"/>
<operation id="cu.masschange.op" isPermitted="true"/>
</role>
</roles>

It sounds like our documentation wasn't clear on this, so I will file a bug on it.

PJoneja

I forgot to address your other question.

You asked: Also - how does one remove "standard" menu options on a per-role basis?

Unfortunately, we do not currently support that. The reason you can completely delete a link but not delete it for a specific role is that the permissions are handled differently.

Migrateduser

Hi Fish!

Here's some answers:

>> Is this functionality that was lost?

Yes it was lost intentionally. Why? Two reasons:
- UITK can only control the UI. It can not control the server. We don't want to introduce a mechanism that would deliver inconsistent results between the UI, CS SDK and the file system. The role configuration for operations should affect the core TS server, not just the UI.
- Flex roles project is on the horizon and we feared introducing a mechanism that could be short lived would be confusing and create migration issues

>> Is it coming back in 6.1?

No. It will come back when flex roles comes, which I don't have an ETA for. One note, the editor switch for publish available in iw.cfg is respected by 6.1.

>> Do I need to file a bug on this?

No, this was flagged as an intentional migration issue in the documentation.

How much of a pain point is this? We do have a fallback position, but we're trying to avoid it because it will most likely cause migration headaches for customers when flex roles comes around. So far the biggest pain point I've heard has been about tt_data in CCP, not this. I know philosophically people will say you shouldn't remove things. I understand. In this case it was to try and make things easier for the future for everyone. So without getting into a major philosophical debate, if you can identify just how much pain this causes we can gauge if a short term measure is worth the long term pain for customers when migrating.

Thanks,
Todd

Dev. Mgr., CCS and UITK

Adam Stoller

I figured out the listing of the operations with 'true' - it was rather confusing though since 'master' saw all the customizations without listing them but 'admin' did not. I'll take this as noted and make sure to list them for each role - but I have to make the comment that the DTD for this seems a rather significant step backwards. Rather than having:<roles>
<role id="...">
<operation id="..." isPermitted="(true|false)"/>
</role>
</roles>I think it would have made more sense, and been more backwards-compatible to do something like the available_templates.cfg file logic:<operations>
<operation id="...">
<role id="(all|master|admin|editor|author)" isPermitted="(true|false)"/>
...
</operation>
</operations>And have it parsed in top-down fashion so that: <role id="author" isPermitted="true"/>
<role id="all" isPermitted="false"/>would mean it would only show up for Authors, and : <role id="author" isPermitted="false"/>
<role id="editor" isPermitted="false"/>
<role id="all" isPermitted="true"/>would mean that it would only not show up for author's and editor's but all other roles would see it.

How much of a pain point is this? [...] So without getting into a major philosophical debate, if you can identify just how much pain this causes we can gauge if a short term measure is worth the long term pain for customers when migrating.

Well, here's my situation. The environment set up for my customer in 5.5.2 dictates that the only way to create a DCR (form) is through a workflow process - so we want to disable/remove the File>New Form Entry menu. Furthermore, previewing of a DCR is handled by a custom process responsible for generating the files in a temporary location, deploying them to a preview server, and then providing links for the user to click on to view the page on the preview server (there's a JSP "clamp" involved) - so we want to remove / disable the Actions>Preview menu item (if I'm interpreting that menu item correctly?), and if you haven't guessed yet, we also handle page generation and regeneration only through the workflow process too, so we want to remove / disable the Actions>Generate and Actions>Regenerate menu options as well.

Within the Form Entry TS6 provides us a nice way to remove the Save As, Preview, and Generate buttons via templating.cfg directives - so we don't have to muck around with FormAPI code to override those functions with alert() boxes telling users that they can't do that (Yay!), but if we cannot disable / remove the menu items we're opening the door to a slew (and I do mean slew :-)) of end-user's getting confused when things don't work because they weren't designed to be interacted with that way.

I'll also go a few steps further - because of the interrelationships we've built into the system between generated pages and their source DCRs, we also need to disable / remove / replace standard functions like: File>Move, Edit>Copy, Edit>Copy To... and potentially Actions>Lock and Actions>Unlock. All of this is possible through officially supported means in TeamSite 5.5.2. None of this is apparently possible through(any?) officially supported means in TeamSite 6.x.

I'm not sure whether or not this is a make-or-break issue for my customer to upgrade to 6.x - I'll have to check with them, but I can certainly see it being a serious issue for them.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

>> so we want to disable/remove the File>New Form Entry menu.

By why by role? You can remove the menu items, just not by role. Is it not sufficient to just remove them?

Dev. Mgr., CCS and UITK

Adam Stoller

New Form, Generate, Preview would be removed for all roles (at least for this initiative), many of the other items like Delete, Copy, Move, etc. we want to limit to only Administrator and Master roles.

I'm going to try out the ideas provided via email and will post the outcome.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Adam Stoller

Okay, using Action > Generate as a test case I removed it from the UI via the ui_custom.xml file with:<?xml version="1.0" encoding="utf-8"?>
<iwov-ui>
...
<menu id="iw.ccpro.action.menu">
<iwov-delete>
<link id="iw.ccpro.action_menu.generate.link"/>
</iwov-delete>
...
</menu>
</action-list>
</iwov-ui>This appears to work as documented, plain and simple (good). Next I wanted to add the functionality back in, but as a custom menu item, so I further modified that section in the ui_custom.xml file shown above as follows:...
<menu id="iw.ccpro.action.menu">
...
<link id="cu.ccpro.action_menu.generate.link"
operationID="cu.ccpro.action_menu.generate.op"
label="Generate Page"
description="Generate page from Form Entry"
refid="_iw.ccpro.action_menu.generate.link"
target="_hidden"/>
</menu>and then followed that up with modifying the roles_custom.xml file:...
<role id="author">
...
<operation id="cu.ccpro.action_menu.generate.op" isPermitted="false"/>
</role>
<role id="editor">
...
<operation id="cu.ccpro.action_menu.generate.op" isPermitted="false"/>
</role>
<role id="admin">
...
<operation id="cu.ccpro.action_menu.generate.op" isPermitted="false"/>
</role>

<role id="master">
<operation id="cu.ccpro.action_menu.generate.op" isPermitted="true"/>
</role>Well, this only shows the menu option for Master, but it doesn't seem to like the menu definition, so I'm guessing I did something wrong when trying to redefine the generate menu option as a custom menu item within the ui_custom.xml file.
Can anyone point me to where in which documentation this is covered?
Can anyone point out what I did wrong and how to fix it?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

PJoneja

fish -

I noticed that you're deleting "iw.ccpro.action_menu.generate.link" but you're using "_iw.ccpro.action_menu.generate.link" as the refid for your custom link. If this isn't just a typo in your email, maybe it's the problem.

Adam Stoller

The id begining with the '_' was the refid of the original, but I tried it without the '_' and I get the same result when I attempt to use the menu item - an error window with the message:
"Command null not found in the command descriptors."

So I'm pretty sure I'm missing something - I'm just not sure what - as I couldn't find 'generate' anywhere else within the customer_src directory structure.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Adam Stoller

Okay, this time I'll use a more realistic (for my environment) example.

Using File > Move as a test case I removed it from the UI via the ui_custom.xml file with:<?xml version="1.0" encoding="utf-8"?>
<iwov-ui>
<action-list id="iw.ccpro.filesys.menubar">
<menu id="iw.ccpro.file.menu">
<iwov-delete>
<link id="iw.ccpro.file_menu.move.link"/>
</iwov-delete>
</menu>
</action-list>
</iwov-ui>This appears to work as documented, plain and simple (good). Now I want to add the functionality back in, but as a custom menu item so that I can control which roles can see/use this functionality, so I further modified that section in the ui_custom.xml file shown above as follows:...
<menu id="iw.ccpro.file.menu">
...
<link id="cu.ccpro.file_menu.move.link"
operationID="cu.ccpro.file_menu.move.op"
label="Move File"
description="Move file"
refid="iw.ccpro.file_menu.move.link"/>
...
</menu>and then followed that up with modifying the roles_custom.xml file:...
<role id="author">
<operation id="cu.ccpro.file_menu.move.op" isPermitted="false"/>
</role>
<role id="editor">
<operation id="cu.ccpro.file_menu.move.op" isPermitted="false"/>
</role>
<role id="admin">
<operation id="cu.ccpro.file_menu.move.op" isPermitted="true"/>
</role>
<role id="master">
<operation id="cu.ccpro.file_menu.move.op" isPermitted="true"/>
</role>Well, this hides the option from Author and Editor (as desired) and shows the menu option for Master and Admin (as desired), but it doesn't seem to like the menu definition, so I'm guessing I did something wrong when trying to redefine the move menu option as a custom menu item within the ui_custom.xml file.

If I try to use the menu option I get an error window with:

Command null not found in the command descriptors. Can anyone point me to where in which documentation this is covered?
Can anyone point out what I did wrong and how to fix it?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

PJoneja

Fish -

Unfortunately, what you are trying to do will not work because the link you are trying to refer to (iw.ccpro.file_menu.move.link) is not a global and therefore is out of scope for your custom link. I recommend that you define your custom links such that they use the CCI URLs.

For your Move example, you can define you link as:

<link id="cu.ccpro.file_menu.move.link"
operationID="cu.ccpro.file_menu.move.op"
label="Move File"
description="Move file"
url="/move" />

-Pam

Adam Stoller

Ah - okay - I think that was the bit of logic I was missing - I'll play around with that and see if I can get that to work (I do recall being told I should use the CCI URLs but I forgot and didn't see anything in the customization documentation that reminded me to look for it)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Adam Stoller

Hmm - well there's still a problem here. Is there more complete documentation for the CCI links than what appears on page 40 of the TeamSite Administrator's Guide for 6.0L ?

There is indicates that the only functions available are:
- assign
- edit
- sce
- tag
- details
- visualdiff

I don't see "move", "copy", "rename", "delete", "generate", or "regenerate" there - so I don't see how I can use a CCI URL to implement a custom wrapper for OOTB functionality without coding the entire thing myself as a custom menu option.

We have custom versions of [some of] these commands but we want to provide Administrator and Master with the OOTB functionality - which was trivial to do in 5.5.2 but seems to be contorted (at best) with 6.0.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

Is there more complete documentation for the CCI links than what appears on page 40 of the TeamSite Administrator's Guide for 6.0L ?

In the UI Customization Guide, there's a section on CCI URL's (Chapter 8) that gives a more comprehensive list. But be aware, there evidently are some undocumented ones as well.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Adam Stoller

Ah - okay there's a 'move' in that list - so I changed my ui_custom.xml to have the following:<?xml version="1.0" encoding="utf-8"?>
<iwov-ui>
<action-list id="iw.ccpro.filesys.menubar">
<menu id="iw.ccpro.file.menu">
<iwov-delete>
<link id="iw.ccpro.file_menu.move.link"/>
</iwov-delete>
<link id="cu.ccpro.file_menu.move.link"
operationID="cu.ccpro.file_menu.move.op"
label="Move File"
description="Move file"
url="/iw-cc/move"/>
</menu>
</action-list>
</iwov-ui>with the roles_custom.xml file:<?xml version="1.0" encoding="utf-8"?>
<roles>
<role id="author">
<operation id="cu.ccpro.file_menu.move.op" isPermitted="false"/>
</role>
<role id="editor">
<operation id="cu.ccpro.file_menu.move.op" isPermitted="false"/>
</role>
<role id="admin">
<operation id="cu.ccpro.file_menu.move.op" isPermitted="true"/>
</role>
<role id="master">
<operation id="cu.ccpro.file_menu.move.op" isPermitted="true"/>
</role>
</roles>then run make.sh followed by iwhome/install/install_webapps.ipl -f -i (wait about 30 minutes... refresh browser window) and This Works!!! - thanks to all who helped with this.

There definitely needs to be better documentation written if this is the only way we're going to be able to limit OOTB menu options in TS6.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

There definitely needs to be better documentation written if this is the only way we're going to be able to limit OOTB menu options in TS6.

Hallelujah!

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

PJoneja

then run make.sh followed by iwhome/install/install_webapps.ipl -f -i (wait about 30 minutes... refresh browser window)
FYI, TeamSite 6.1 contains new customization features which significantly decrease the time it takes to build and test your customizations.

-Pam

Adam Stoller

I'm hoping to have my 6.0L system upgraded to 6.1 sometime between now and the end of next week - I look forward to seeing that go a lot faster.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Adam Stoller

(I haven't gotten to a 6.1 system yet - I'm going by the documentation)

6.0 / 6.0L uses the 'make.sh' (or 'make.bat' located within the customer_src/ directory
6.1 uses 'make_toolkit.ipl' located within iwhome/bin/ -- but the documentation states that you must explcitily cd into the customer_src/ directory before running this CLT.

Why?

If you need to be in that directory - why doesn't the CLT do something like:use TeamSite::Config;
my $iwhome = TeamSite::Config::iwgethome();
chdir("$iwhome/local/config/lib/content_center/customer_src") || die "... ($!)"
...

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

What a pain!!! We are used to restricting IWOV provided menu options by roles in TeamSite 5.5.2. Now we have to delete OOTB links and re-create them using URL command?! Is there a easier way now in TS 6.1?

Gregg Faus

No. This is the only way. With the increased amount of functionality it's quite obvious the old way of adding items iw.cfg just doesn't work anymore.

This should be the least of your worries when migrating to 6.x.

Migrateduser

I just started the migration. What are the other "worries" that I will be experiencing soon? I want to be prepared.

Gregg Faus

There are plently of discussion on this topic. Do a search for "migration".

Custom scripts, template conversion, app customization, CCI paths, etc... are all issue I had to deal with. I've been running 6.1 since early May and my end users really like it. Looking forward to 6.1 SP1.