cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - You can subscribe to a forum, label or individual post and receive email notifications when someone posts a new topic or reply. Learn more! X

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

RandyJones
19-Tanzanite

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

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.

 

 

comparision_tasks_table.png

 

 

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

 

tasks_table_removed.png

 

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

 

Anybody here have ideas for me to test?

 

 

ACCEPTED SOLUTION

Accepted Solutions

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');

View solution in original post

14 REPLIES 14
TomU
23-Emerald IV
(To:RandyJones)

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

TomU_0-1673460904496.png

 

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

 

TomU_1-1673460963704.png

 

TomU_2-1673460999886.png

 

TomU
23-Emerald IV
(To:TomU)

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

 

TomU_3-1673461198072.png

 

RandyJones
19-Tanzanite
(To:TomU)

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

 

base_license_profile.png

 

RandyJones
19-Tanzanite
(To:TomU)

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
23-Emerald IV
(To:RandyJones)

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
23-Emerald IV
(To:TomU)

@RandyJones,

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

TomU_0-1673889281183.png

 

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

RandyJones
19-Tanzanite
(To:TomU)

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
23-Emerald IV
(To:RandyJones)


@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

TU_4363690_0-1673917900681.png

 

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

TomU
23-Emerald IV
(To:RandyJones)

@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
19-Tanzanite
(To:TomU)

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
19-Tanzanite
(To:TomU)

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
23-Emerald IV
(To:RandyJones)

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!

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>

 

 

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');
Announcements


Top Tags