"My Tasks" table missing the 3 multi task related icons/actions after upgrade 12.0.2.9 to 12.1.2.0

[RandyJones]

After upgrade from 12.0.2.9 to 12.1.2.0 the "My Tasks" table on the home page is missing the 3 multi task related icons and actions. The 3 missing icons/actions are: Accept Tasks, Reassign Tasks, and Decline Tasks.

I have not made any changes to anything related to roles besides upgrading that I am aware of.

This affects all users except for wcadmin. In the screenshot below the left is "normal" user and the right is wcadmin. Note the 3 highlighted icons and actions for wcadmin that are missing for the normal user.

Digging into it with jcaDebug=1 shows these are actually "removed by role-based check". See screenshot below:

I do have a call open with PTC but haven't gotten any solution yet.

Anybody here have ideas for me to test?

[TomU]

They show up fine for my 'normal' (non-administrator) user account.

Take a look at the profile(s) associated with your user account.

[TomU]

Also look at the license profiles associated with your account.  For example:

[RandyJones]

I had not looked at that however mine are as expected:

[RandyJones]

Thanks for the confirmination the "My Tasks" table actually does work in 12.1.2.0.

I just added a new test user to one of my test systems that belongs to only 2 profiles. Both profiles have all the *Tasks actions checked and the My Tasks table for this test user has the same issue.

[TomU]

Caveat:  I am on 12.1, but it's actually 12.1.1.2.  I'm downloading 12.1.2.0 right now.  I'll let you know how it goes...

[TomU]

@RandyJones,

Sorry for causing any confusion.  I am seeing the same issue on 12.1.2.0 as well (after installing the update).

Is there an SPR open for this yet?  Any idea when it will be resolved?  Thanks.

[RandyJones]

No spr yet. It would be good for you to open a case also. Our case numer is c16698063. Please feel free to reference that.

I have discovered some more strange behavior on a test system:

• Create new test user and add to system and add them to a license group: eg Windchill Base but not to a group
• Login as test user and the My Tasks table actions shows
• Add the test user to one of our Org level groups as is standard practice
• The actions now are hidden for the user
• Remove the user from the group
• The actions are now visible
• Re-add the user to the group
  
  • We have custom Org level profiles in which these groups are members
• Edit the custom Org level profile the user belongs to and remove the group as a member
• The actions now show
• Re-edit the profile and re-add to group as a member
• The actions are now visible!
• As a matter of fact these actions are now visible to other users also
• Restart Windchill and the actions are still visible

So it seems that editing one of the custom Org level profiles by removing a group somehow "regenerates" the role based checking perms. I sent a video of this to PTC but haven't heard back from them yet.

[TomU]

---

@RandyJones wrote:

• Edit the custom Org level profile...

---

Simply editing each profile, without making any changes, seems to be sufficient to get things working correctly.  Something is probably being added or updated in the database when 'Finish' is pressed, and this version of Windchill must be depending on whatever it is.

Test Method:

1. Create a bunch of new test users.
2. Assign each user to a unique license.
3. Log in as each user and check actions.  (Actions appear correctly.)
4. Add test users to existing site profile.
5. Log in as each user and check actions.  (Actions are now missing for everyone.)
6. Edit existing profile
7. Log in as each user and check actions.  (Actions appear correctly again.)

I'm guessing the issue is probably related to the change in this article.  It's just weird that it didn't show up until 12.1.2.0.  (My production system is on 12.1.1.2 and does not have this issue.)

https://www.ptc.com/en/support/article/cs364774

The upgrade manager (or update tool) probably needs to a step added to automatically recalculate all custom user profiles.

[TomU]

@RandyJones,

Could you please see if 'Save As' is working correctly for you on 12.1.2.0?  After updating I'm not experiencing the issue described above, but I'm completely unable to get the 'Save As' page to finish loading for any object that has other dependencies. (Drawing, Assembly, etc.)  I just get the 'spinning wheel of death'.  I'm really curious if you are seeing the same thing.

[RandyJones]

Save As works for me. I am using Creo Parametric 9.0.3.0. From embedded browser workspace:

• Select assembly or drawing
• File > Save As
• From the Workspace Save As table
• Dependents > Required
• The save as table now populates with the needed dependents
• Change number, file name, name as needed
• Select Finish
• The new objects are created in the workspace

[RandyJones]

Have you customized saveas.js?

codebase/templates/uwgm/cadx/saveas/saveas.js

If so PTC has changed that in 12.1.2.0 (at least over 12.0.2.9) and you will need to merge PTC's changes into this.

[TomU]

Yes, that's exactly it.  I started suspecting the same thing shortly after my post last night but wasn't able to confirm until this morning.  I had modified this file in the past to exclude formats during 'Save As'.  Thanks!

[RandyJones]

More information on this. PTC has changed the action definitions on these from 12.0.2.9 to 12.1.2.0. The change is these actions now include a  uicomponent="WORKITEM_MULTI_xxxxx".

12.0.2.9 action:
<objecttype name="work" class="wt.workflow.work.WorkItem" >
      <action multiselect="true" name="multireassign" selectRequired="true" >
            <includeFilter name="projectM4D"/>
            <command method="multireassign" class="com.ptc.netmarkets.work.NmWorkItemCommands" windowType="popup"/>
      </action>
</objecttype>

12.1.2.0 action:
<objecttype name="work" class="wt.workflow.work.WorkItem" >
      <action multiselect="true" name="multireassign" uicomponent="WORKITEM_MULTI_REASSIGN" selectRequired="true" >
            <includeFilter name="projectM4D"/>
            <command method="multireassign" class="com.ptc.netmarkets.work.NmWorkItemCommands" windowType="popup"/>
      </action>
</objecttype>

I have discovered that redefining the actions and removing the uicomponent="WORKITEM_MULTI_xxxxx" restores these missing actions to the "My Tasks" table. So for a workaround until the real issue is figured out I have redefined these 3 actions in custom-actions.xml as follows:

<!--
	From NetMarkets-actions.xml
	Redefine to delete the uicomponent="WORKITEM_MULTI_DECLINE" part of the action.
	This is new in 12.1.2.0 over 12.0.2.9 and is causing these actions to be hidden
	for all users except for wcadmin in the My Tasks table.
	See https://support.ptc.com/apps/case_logger_viewer/auth/ssl/case=16698063
	
	This is a workaround until we can come up with a permanent solution.
-->
	<objecttype name="work" class="wt.workflow.work.WorkItem" >

		<action multiselect="true" name="multiaccept" selectRequired="true" >
			<includeFilter name="projectM4D"/>
			<command method="multiaccept" class="com.ptc.netmarkets.work.NmWorkItemCommands"/>
		</action>

		<action multiselect="true" name="multireassign" selectRequired="true" >
			<includeFilter name="projectM4D"/>
			<command method="multireassign" class="com.ptc.netmarkets.work.NmWorkItemCommands" windowType="popup"/>
		</action>

		<action multiselect="true" name="multiunaccept" selectRequired="true" >
			<includeFilter name="projectM4D"/>
			<command method="multiunaccept" class="com.ptc.netmarkets.work.NmWorkItemCommands"/>
		</action>

	</objecttype>

[RandyJones · Accepted solution]

Getting back to this issue. PTC has created article CS392919 and spr 14614107

Description of the spr is this:

"After windchill upgrade from 12.0.2 to 12.1.2, UIAccess records for newly introduced uiComponents (such as WORKITEM_MULTI_REASSIGN, WORKITEM_MULTI_ACCEPT, WORKITEM_MULTI_DECLINE) are not present in database table UIAccess for already existing custom"

The workaround in the article is to export and re-import all custom profiles. Which after doing so will add entries in the uiaccess table. So like @TomU mentioned the upgrade manager failed to "recalculate all custom user profiles".

One can inspect the lack of and the change to these uiaccess entries by using  the following sql query before and after re-importing the profiles or editing the profiles:

select *
from UIAccess 
where ida3a3 in
(select ida2a2 from standardprofile 
where name like '<Your custom profile name here') and uiComponent in ('WORKITEM_MULTI_ACCEPT','WORKITEM_MULTI_REASSIGN','WORKITEM_MULTI_DECLINE');