Clarity

We have CA PPM 13.3.

On one system there is a field on the application side in the resource edit properties view in a section which does not match the definitions in the administration.

We have removed the field and set it back and published - no change still mismatch.

We tried to create a new section to put the field in there but the application does not allow that.

On a second system no problems.

There are no locks on the locks page or in prlock.

What other things to look than the logs and trace.

We have partitions. This occurs in one of the partitions. In other partitions the view is different.

"We tried to create a new section to put the field in there but the application does not allow that." - What error message do you get ?

Can you share some screenshot of field from both the systems (admin side) ?

NJ

Hi Urmas,

Did you login on the both the systems with the same CA Clarity user account or different? Did you also check the default Partition for these user accounts? It would be better if you would upload some screenshots of the field available both on the Resource Application and Admin side.

Suhail.

Can you try to remove and recreate the field?

The problem occurs with several users, several workstations, and while looking at several resources.

We did remove the field and put it back and published the views.

When trying to create a new section I did not get an error. So I dod not get anything from the log.

This is what the definitions looks on the admin side

Before openings the views we selected the proper partitions. Otherwise we would not see the fields we want to see.

On the application side the edit resource properties for the same partition looks like this

When i query the  ODF_VIEW_ATTRIBUTES for the resource edit views in the systems there is no view in the system which has those field in that sequence.

There is view matching what I see on the admin side,.

Hi,

Some actions to try:

- do you try flush the caches (action:security.caches)?

- if you add another attribute to the view, the attribrute is displaied for the users with the problem?

- extract the XOG of the views and check if on the XML the attributes are positioned as expected. Check if there are more than one propertySet tag for resource (for a given partition).

- [do not this on production without your backups are updated!] can you XOG back in this view to see if the problem is resolved?

- if the previous action do not work (or you are unconfortable with it), try to create another edit subpage, identical to the one with problem, and check if the users are able to see it correctly. If so, you can remove/hide the view with problem and replace with the correct one.

Thanks for your input. Somewhat similar to what we are trying.

1. Have not flushed the caches. Will do that when back on site again.

2. Nothing we do in the view configuration is reflected on the application side. Therefore I don't think creating another subpage will work until we can control that the users see what we configure on the admin side them to see.

3. Yes XOGing the resource object from both systems out and comparing the output files could tell something. Have not done that yet because I am afraid it is going to be 10 - 30 megs and would have to limit it just to edit property views in those multiple partitions  to get them smaller. Not that lucky with limiting before read, though OK selecting the part of the output I need.

4. Must try again creating the new section. Another debugger got an error and I did not, but then I did not see the correct fields for that partition. SO maybe my partition selection was not correct after all.

5. If when I query the  ODF_VIEW_ATTRIBUTES for the resource edit views in the systems there is no view in the system which has those field in that sequence in the problem system I must run the query on the other system to see if I get a match there. If I do then that is starting to point further to the cache.

6. If there no error in the GUI no error is expected to be in the logs either.

However, is it possible to see in the logs what is actually configured or where to the configuration is supposed to go from the logs or from a trace?

I should expect the trace to catch and update statement.

Any other thoughts anybody? We've nearly pulled all of my hair out and if you know me I did nto have that much to start with.

Hi,

Still with the problem? Any luck pulling the resource defintion XOG? You can try to use <args name="no_dependencies" value="true" /> to make it smaller (if you are not using this tag....).

I think that a good shot is extract the resource definittion XOG, and than inserting it back on the server.

If this do not work, you can try to do this again, but before push the xog data, reset the views on Clarity. (please try that on a test environment first!)

You said that in this environmnent there are more than one server running arr, right? The problema is happening in all servers, or in only some of them? Are you able to test it? You said above that "On a second system no problems." and I assume that you are talking about another Clarity environmnent, and not a different node in the same Clarity cluster. Is that right?

Are there multiple servers?

If so is this behaviour the same on all the servers?

Thanks for the reminder. I remembered that over the weekend, but forgot by Monday morning.

Yes we do have two servers, but I can't access them directly have to have somebody else to verify the views.

I take Dave's options in

https://communities.ca.com/message/17835601#17835601

are still valid.

Restarting the app services (from CSA) did not do it.

What other options do you have if you cannot bypass the load balancer, SSO and the two stage authentication?

That's annoying.

it does sound like to me a multicast issue, are these servers virtual?

if so make sure they are on the same host

No they are not virtual servers.

We recently found an issue with the resource object in Clarity 13.2. Where the resource object is associated to our partition, Changes to the Resource Object in our partition cannot be viewed unless they are performed in the System partition. So we are now removing the resource object from our partition and doing all the changes in the system partition.

That is interesting.

Say you had partition specific definitions of the resource views. Would you then have with display conditions or in some other manner?

mike2.2

Is the bug confirmed by CA and is there a CRTL number for it?

Hello All,

Just out of curiousity - isn't this correct? -> that if a particular Clarity Resource is tagged to a specific Partition Model such as zzz and the second Clarity Resource is tagged to a Partition Model such as yyy. So, if the attribute x is placed on the Partition View of zzz, then the attribute x can only be visible to the Clarity Resource tagged to the Partition Model zzz and not to the Clarity Resource tagged to the Partition Model yyy. And, this applies to any system that those 2 Clarity Resources are working from.

I do apologize if this is of no relevance to this post. But, I just wanted to clarify this.

Many Thanks,

Suhail.

We had one partition under system called XXXX. The all objects were members including the resource object of the XXXX partition. We would update the resource object in the XXXX partition, and a user in the XXXX partition counld not see the updates. Any update to any other object in the XXXX partition was visible, just not updates to the resource object. So we had to do all of our updates in the system partition for the Resource object.

Note: we also did not use any display conditions.

We gave up on support. We simply decided to remove the Resource object from our XXXX partition and make our changes to the resource object in the system partition. everything works that way.

Thanks mike2.2

Our experience is somewhat similar to yours.

We have one active partition model and several partitions in hierarchy under it.

Many of the objects are associated to the partition model (not to individual partitions) the resource object being one.

After digging deeper and having a little better understanding what we see appears to be:

For the resource object which is associated with the partition model there are a number of attributes.

Many of them have partition mode Partition, ancestors and descendants, some

Partition and descendants

Consulting manager is Partition only and the partition for that attribute is Urmas.

On both system we have in the administration there is no problem configuring the resource edit properties view for the system partition and Urmas partition, save them and to open them during the next login time and they are exactly as saved.

The problem is on the application side.

On one system the users (not just me, but also others) can only see the resource properties as defined for the system partition and on the other one as defined for the Urmas partition.

When we temporarily change the partition on the resource list view before opening the properties of a resource it will have no effect. We do not see the view as defined for the select partition.

If we change the default parameter for the resource object in the account setting (log out and in again) there is no difference we still see the resource properties defined for the same partition.

As a temporary work around for the time being we have changed the partition mode of the Consulting manager Partition, ancestors and descendants. The downside is that now everybody can see who is the Urmas Consulting manager for any resource they can view. That really makes the association of the resource object with a partition model obsolete.

I think we could put that field on a subpage with display condition, but have not done that yet.

There reason being is that we should like to be assured that using partitions which we have already set up can't do it for us.

Still anxiously interested in comments, options and education opportunities in this.

Basically yes, but you can make a user a member of more than one partition in the administration.

Secondly you can set the default partition for each partitioned object in the user account settings on the application.

Thirdly if you are a member of more than one partition you temporarily switch the partition in the object list view before you open the properties of an instance.