Searching against workflow state

Rhythmyx Technical Discussion
1

Using Rhythmyx 6.5.0 I want to customize the default search to add the workflow state as a search option.
After adding the workflow (sys_workflowid) and the workflow state name (sys_statename) to the list of selected search fields no workflows or workflow states appear in the list even after selecting a Community and/or Content Type. Tried this in the workdench and by customizing a search in Content Exlplorer.

Does something else have to be done to populate the workflow list boxes?

2

Jason,

I just wanted to let you know that I’ve seen this on my local development server, but it works properly on all of the other servers that we’ve tried it on.

We’re investigating to see what’s different about my server and I’ll let you know when we find something. I believe that Tech Support has a copy of your system. Can you confirm that is up to date?

Thanks

Dave

3

Jason,

We’ve tracked down at least one potential cause. This can happen when the sys_workflowid field gets “overridden” in one or more content editors. In my system, this happened in the rffContacts content type, so that’s the first place to look (it could be in another content type in your system).

Edit the /Rhythmyx/ObjectStore/psx_cerffContacts.xml file, and find the <PSXDisplayMapping> node for sys_workflowid. It will look like this:


<PSXDisplayMapping>
     <FieldRef>sys_workflowid</FieldRef>
     <PSXUISet accessKey="w">
          <PSXChoices sortOrder="ascending" type="internalLookup">
              <PSXUrlRequest>
                   <Href>../sys_commSupport/communityworkflows.xml</Href>
                   <Anchor/>
              </PSXUrlRequest>
              <PSXChoiceFilter>
                      <DependentField dependencyType="required" fieldRef="sys_communityid"/>
                      <DependentField dependencyType="required" fieldRef="sys_contenttypeid"/>
                      <PSXUrlRequest>
                          <Href>sys_psxContentEditorCataloger/WorkflowContentTypeCommunityLookup.xml</Href>
                          <Anchor/>
                     </PSXUrlRequest>
               </PSXChoiceFilter>
           </PSXChoices>
      </PSXUISet>
 </PSXDisplayMapping>

Note the 2 nodes in this XML. There should be only 1 of them (for community id, not content type id).

To fix this, you’ll need to edit the XML and remove the node.


<PSXDisplayMapping>
     <FieldRef>sys_workflowid</FieldRef>
 </PSXDisplayMapping>

After you’ve done this, you’ll need to restart the content editor for that content type. If you need to add any customization, go back into the Workbench and re-add the control.

I hope this helps, and let me know if you have more questions.

Dave

4

Dave,
That fixed it - many thanks for this. It was the rffContacts content type in our instance also.

Regards,
Jason.

5

We suspect that this content type was incorrect in some versions of Fast Forward. Depending on what version of the system was originally installed, you might experience this problem, even with systems that have subsequently been upgraded.

We do know that it is fixed in the current (6.5.2) Fast Forward installation (and also probably 6.5.1). When it does occur, the safest thing to do is edit the content editor XML as described in my previous post.

I’m glad this resolved your issue.

Dave