Change in Filter not reflected

[Monica_Rampradeep_Raj]

Hi

 

I tried to add a new filter field to the Resource planning -> Unfilled Roles portlet page. It's a virtual field and I added it to filter view in Team object and published it. Still the field is not showing up. I tried to make the virtual field as required field in filter and entered a default value too in the filter view. Yet this is not showing up in the Unfilled roles portlet page. Any idea on what is causing this issue? Why is that not reflected in the Unfilled Roles filter section?

 

Any idea on this issue would be really helpful. Thanks in advance.

[Jeevan.B]

If the Data Provider is a System Restricted Provider, then all the fields that appear in the Portlet would be predefined and not open for change.

[Monica_Rampradeep_Raj]

Jeevan, I can see the field when I customize it. But it's simply not reflected even when I try publish button.

[kumni11]

Jeevan is correct, it is system provider based portlet and fields are already predefined for the portlet to use.

You may play around with the already available fields but new additions will not be possible. You may create a new virtual attribute at the portlet level but still that will not be available for Filter view.

[David Morton]

Perhaps I'm reading this wrong, but I am understanding that we have been able to add the field as a filter in the portlet setup in studio OK, just that it is not reflected in the application - I think that this is different to what you and Jeevan are saying which is "you can't add fields to system data providers".

[Roland Parrotte]

You can add virtual attributes to some 'system provider based portlets'.  For example, push over a Investment attribute to the Team via the Object Team.  The Investment attribute is then available to portlets based around the 'system provider' 'Actuals vs Allocation Discrepancy' which can be used for example, in the portlet 'Allocation Discrepency' which I have used as part of the Filter to only show only those investments with the Investment attribute = 'X' or 'Y' etc.  It doesn't work on all 'system providers' though.

[David Morton]

If we make changes to object views in studio, then a user will not inherit those changes if they have previously configured their own personal view of that object-view. In order for a user to pick up the studio-configured changes then you must either;

• PUBLISH the changes from within studio (but this affects the whole system (i.e. all users) and this might not be what you want to happen if you have other users with personally configured views)
• As the user, "Restore Defaults" against the personalised view - you would need to do this for every user though so that also has its problems

[Monica_Rampradeep_Raj]

Hi David, I tried publish too. Yet the newly added filter value is not reflected in the page. Still, I can see that when I try to configure the page.

[David Morton]

Its not "hidden in filter" is it (since you have said required and given it a default, you are able to hide it)

 

(hard for me to guess as I'm not very familiar with that page/portlet)

 

What do you see when you configure the portlet from the user-side of the application (rather than studio)

[Deactivated User]

If everything else fails try this
Issue adding filter columns to portlets 

[Garrett Steudle]

I have noticed this issue as well when I publish changes to portlets.  I finally figured out the issue for me was I needed to run the Clean User Session job.  Once I run that job, the changes are reflected in PPM.

[Deactivated User]

That is doable, but if the policy is to run the job scheduled should you launch it manually?

[Garrett Steudle]

I do not have that limitation, especially for a portlet  since I only have to run it in our Dev environment.  Once I'm done building it in DEV, I XOG it into Test and Prod.  However, I have had the same issues when I make changes to a view which would require me to run the job in all three environments.  That being said, couldn't you just schedule the job to run at least once a day and therefore you know your configurations will be done on the scheduled time.

 

Either way, any of the suggested solutions, XOG out and then back in or run a job, should not have to be done.  PPM should automatically reflect the changes you make as soon at you hit SAVE.

[Deactivated User]

Agree that no special action should be needed.

I think Georgy suggested just exporting the portlet and XOGing that back, which is a little bit simpler.

However, I think the least risk it in running the job.

Running the job once a day would force you to wait a day before you can verify the modification.

 

Just wondering again ...

How did you establish that the running the job solves the issue?

[Garrett Steudle]

That's why I said to run the job at least once a day or else like you stated you would have to wait any entire day for the change.

 

I started noticing that when I made some portlet configurations that the changes would show up in PPM the next day.  I figured it had to be some job that was running so I took a look at the scheduled jobs that ran off hours.  The one that made sense was the Clean User Session job and then I tested it out. 

[Roland Parrotte]

Try flushing the cache via yourenv.ondemand.ca.com/niku/nu#action:security.caches.

 

We periodically have the same issue, and we run the Clean User Session nightly, as well as I republished the portlet etc, and I had the same issue, where a filter attribute would not show, even though I could see it when I went to configure the portlet in my personal session.  Flushing the cache worked in this case.

[Monica_Rampradeep_Raj]

This is now added to the portlet filter and is working as expected. It should be the cache issue. Thanks you guys for all prompt response.