Portlet with busted Default Filter

[Robert_Ensinger]

Hi all.
Does anyone know if its possible to "backdoor" into Manage Filters on a portlet? I have a manager with a busted default filter (Portlet Errors with ye ole Error 500). I've reproduced the error and can fix it, but since they have this filter set as their default, the portlet errors on load thus I have no way to get to the manage filters to fix it. Little Catch-22.
I've exhausted about everything I can think of from a URL perspective to attempt to get into the Manage Filters for this. I'd prefer not to goto the database, but if I must I must.

If anyone has addressed this before I'd love to hear how you've fixed this.

Off to open a ticket...

[Anon Anon]

Could try constructing the URL to go to the configure page. Easiest way might be to set up the same page and portlet in your account and then go to configure there. Copy the URL, log into the users account, and paste the URL. It worked for me using my account and the main admin account (only both have pretty much system wide permissions so you may need to modify some permissions if at first it doesn't work).

[Robert_Ensinger]

Thanks Ni, here's what I tried: I set the portlet globally to "Do not show results until I filter", back doored into the Configure in the user's UI via the URL, clicked restore defaults, logged out, flushed system cache for good measure, logged in as them again and tried to load the page again hoping the filter wouldn't run and I'd be able to get into the Manage screen... but the saved filter still ran on load. :wacko:

Did I miss a step with the above?

[Anon Anon]

Rob, you tried what I was thinking and then some. In this case, the system logs might be able to explain in depth what is causing the error 500 on the screen. Other than that, I think the CA support case might not be a bad idea.

[Robert_Ensinger]

Thanks Tom - issue has been opened. Yes, it was the logs that gave me the filter parameters to reproduce this and isolate/reproduce this via filtering in my portlet.

This has forced me to think about this a good bit and I plan to open an enhancement request once resolved - something to the extent that, if a portlet has a filter related fail on load, fail a little more gracefully so as not to lock the user (or the administrators!) out from correcting the filter issue. Similar to the error 500 of simply running a bad filter on a working portlet.

Yes, a small issue, but this is affecting a valued user and I want to do my best for them. I'm just a little frustrated that this simple problem is outside of our out-of-the-box administrative toolset to resolve.

When I get this resolved I'll post up my results for future Knowledge.

[Anon Anon]

Rob, see this thread;

2299679

If I follow you right, this is the same as what you are experiencing?

Dave wrote:

To unconfigure a "broken" portlet try this; Log on as a different user (one who the portlet is OK for), go to the portlet that is broken for the other user and select "Configure". Then grab that URL from the browser. Now log on as your "broken" user, and paste the URL into the browser. You should then be in the "Configure" screen. Go to General and select "Restore Defaults". 

(This is the same advice that nriordan is suggesting in post#2 above)

[Deactivated User]

More options in a case of a portlet like this is to XOG read it out and try to see if the problem can be fixed in the xml file, and write it back again.
If it is on a personal tab on the overview page then you can just drop the portlet from the content and add it back again with the defaults.

Martti K:

[Robert_Ensinger]

Thanks all. Yes Dave, I found your post early in my research (Thanks again!) and backdoored into configuration, unfortunately this is not a configuration issue, the issue is a default filter with a bad value. What I really need to do is backdoor into the Manage Filter screen to set another filter as a default so I can get the portlet to load for the user & make the necessary changes. If it's possible to fix this via configure and I'm simply missing it (steps I've tried above) please let me know. Same thing here Marti - portlet is good, the user's filter is bad. Not a Xog fix here, but either a UI trick into the Manage Filter screen or a query to restore the user's filter to the system default.

... still working it - lemme know if anyone has any other ideas.

Thanks!

[Anon Anon]

Ok, applying the same principle;

Logged on as a user that does not have the "default filter" problem, navigate to that portlet's "Manage Filters" page and grab the URL from there.

Then logged on as the user with the problem, paste that URL into the browser and you should be able to remove the errant default.

Does that work? There is a database-side solution to removing the default filter for a portlet, but I'd have to dig about a bit to "remember it" (I will do though if the above doesn;t work! :bashful:)


EDIT : just tried it myself, seemed to work, but I needed to force-refresh (shift F5) my browser when I logged on as the second user, because IE had cached the page. YMMV! :blink:

EDIT2 : you could even just email the URL to the affected user and get them to remove their "default" (assuming they are savvy enough to know what you are doing!)

[Robert_Ensinger]

The URL trick isn't working in our environment.

Below you can see the URL and the Manage Filter screen when I go directly to it via the Manage Filter selection in the portlet. I copy the URL, navagate away (still in my session) and paste the URL in and get the results in the bottom image. The portlet I'm trying to fix is on a tab on the Overview, I've tested this on portlets on tabbed pages, stand along pages, almost everything I can think of even different browsers (IE8, FF 3.6.6, Opera 10.6) - still get the blank Manage Filter screen that's lost the Content. We're 12.0.5.

Thanks everyone, but this looks as if it's going deeper than a UI work around...

[Anon Anon]

Hmmm... that URL doesn't appear to have any "portlet context" in it does it? That looks like a wild-goose chase then! Sorry!

--

Give me a few minutes, I'll dig out the "database fix"!

--

EDIT : OK here it is;

Run this;

select id , name , is_default
from
cmn_attribute_value_sets
where user_id = ( select user_id from srm_resources where unique_name = '[color=#EE1D1D]<<PUT THE RESOURCE ID HERE>>[color]' )
and view_code = ( select to_char(id) from cmn_portlets where portlet_code = '[color=#EE1D1D]<<PUT THE PORTLET CODE HERE>>[color]' )
order by id desc

"Resource ID" being the resource Id (d'uh) but the "portlet code" is the technical name (id) of your portlet.

Experiment a bit with your user / the portlet to check you get the right record.

--

Then just UPDATE the CMN_ATTRIBUTE_VALUE_SETS setting IS_DEFAULT = 0 for the ID that the SQL above tells you.

(and commit this - I often forget to do that! :-( )

?

[Robert_Ensinger]

Thanks Dave. Looks like this'll get it done. My Dev & Test are down awaiting a restore back from Prod, I'll update with results as soon as the systems come back online.

[Robert_Ensinger]

Awesome Dave! That got me there!

Slight difference in MSSQL from Oracle, MSSQL version below.

select id , name , is_default
from
cmn_attribute_value_sets
where user_id = ( select user_id from srm_resources where unique_name = '<<resource id here>>' )
and view_code = ( select cast(id as char) from cmn_portlets where portlet_code = '<<portlet id here>>' )
order by id desc

Thanks all!

[Anon Anon]

Rob, thanks for sharing the MS SQL version. As usual, Dave, thanks as well. This is a nice code to keep in your back pocket.