Error when viewing roles in the workbench

Hi

I get the attached error when view the workflow and unsigned roles in the workbench (6.5.2). All I’ve done is created two new workflows and my shared fields. I’ve applied the shared fields to a ff content type to test them, assigned the workflow to the ff content type. But when i try and view the role i get this error.

any clues?

Cheers
James

If my eyes were better, I might be able to help you.

Could you tell us what the error message says?

Dave

<error occurred>:com.percussion.client.PsModelException: org.apache.commons.beanutils.ConversionException: com.percussion.services.workflow.data.PSWorflow@11ca6bf[id=6,name=BS Standard Workflow,description=This workflow requires two approvals before content (It then goes off the screen and i can see the rest)

Cheers
James

There’s probably a stack trace in the workbench log. If you could post it here that might help.

To view the log, click on “Help - About Rhythmyx Workbench”, press the “Configuration Details” button, and then the “View Error Log” button. (This is all standard Eclipse functionality).

If the workbench isn’t running, you can find the .log file is in the Eclipse Workspace in the .metadata folder.

Hi Dave

I’ve attached the log for this particular error.

Cheers
James

Are you sure that both the Server and the Workbench are running the same version of Rhythmyx?

This type of exception usually happens when there’s a “mismatch” between the data that the Workbench receives from the server and what it was expecting.

Dave

Hi Dave

yes they’re both

Version: 6.5.2
Build id: 200710R01 (3173)

I’ve also tried using the workbench on the server and i get the same message.

Cheers
James

What happens when you examine these roles in Server Admin client? (I presume you created them in the Admin client, not the Workbench).

Are there any users in these roles?

Dave

Hi Dave

It’s just the standard set of ff roles with one exception, I’ve created a “Approver” role and assigned the admin1 user to it.

Cheers
James

I’ve tried creating roles in the Server Admin (both ones that have users and empty ones) and they all show up in “unassigned” roles in the workbench without any errors.

I’m also running 6.5.2. build 3182. Although this is slightly more recent than what you are running, I don’t see anything remotely like this in the bug history.

Dave

Hi Dave

I’ve managed to find the source of the problem. I’ve copied the “Standard Workflow”, then removed the “Web_Admin” role from the list of workflow roles in the content explorer. However I do not get the error message in the workbench if I remove the “QA” or the “Editor” role.

Cheers
James

Hi Dave

Do you experience the same behaviour? and if so is the Web_Admin role tied into the workflow in some way which is why the error occurs when it’s removed?

Cheers
James

I can reproduce the behaviour, but I have no idea what causes it.

The Web_Admin role is listed as a transition role in the Republish and Direct To Public transitions in the standard workflow. Removing the role from the workflow leaves “orphaned” references to the role in the transition configurations.

This has already been logged as a bug and is scheduled to be fixed in the next release. The bug ID is RX-12603.

We are currently looking forward to addressing this issue in the next point release of the product. In the mean time, the workaround is to add the missing role(s) back to the parent workflow. Remove the transition role links for this role. Then remove the role from the workflow.

Hi,

We’ve had this issue since around the start of year, but somehow missed this forum thread until now. Nobody could help us so we have been ignoring it, hoping it was a display bug and not the sign of some deeper problem with our 6.5.2 system.

I’m sure it has been mentioned before, but could you remind me when the “next point release” will be?

Thanks,

Andrew.

The estimated release of Version 6.6 is currently early next year.

Waiting nearly a year for a serious bug fix is pants!

Can this not be a patch fix?!

Just noting that this is not resolved in a base install of Rhythmyx 6.6.1.

The “work around” is still valid.

We may need to upgrade the situation from “pants” to “naff”.