Video Screencast Help
Search Video Help Close Back
to help
New in the Rewards Catalog: Vouchers for "Symantec Technical Specialist" and "Symantec Certified Specialist" exams.

How to hide Notify Rules in Incidents View

Updated: 21 May 2010 | 8 comments
lryker's picture
0 0 Votes
Login to vote
This issue has been solved. See solution.

Does anyone know how to hide the Notify Rules in the Incidents View?  I realize it might mean a customization, but, I'm ok with doing that. We have alot of rules and they literally take up a foot of line space in the view.  I want to continue to see th Rules applied, but, we don't need to see all teh Notify Rules (our workers complain about it). Thank you. Laura

Comments

bgreen's picture
29
Jul
2009
0 Votes 0
Login to vote

Hide from View or Edit?

Are you trying to hide the Notify Rules from the worker view or edit page (or both?).  Do you want to hide all of the rules in the "Notify Rules:" section?

mccarthy.cw's picture
29
Jul
2009
0 Votes 0
Login to vote

 I am pretty sure you just

 I am pretty sure you just need to uncheck the visible checkbox when editing the Notification rule.

Tenacious Geo's picture
29
Jul
2009
0 Votes 0
Login to vote

 yes, i was thinking the

 yes, i was thinking the 'visible' checkbox too

-Geo

MBHarmon's picture
29
Jul
2009
2 Votes +2
Login to vote

Yeah, even if you uncheck the

Yeah, even if you uncheck the visible box it will still show up on the worker View page. 

I see where you can cut the section that shows all rules were executed, but just not how to cut only the one yet.  If you edit the WorkItemView.ascx you can cut all of those by deleting this section.

<aw:Panel id="PanelRulesFired" runat="server" label="sidLblWorkItemRulesFired" labelposition="top" colspan="4" width="100%">
<UL>
<aw:repeater id="rptRules" runat="server" DataMember="CurrentRuleHistory" DataSourceName="WorkItem">
<ItemTemplate>
<li>
<aw:Map ID="mpRuleType" ItemDataSource="<%# Container.DataItem %>" ItemDataField='wuci_custom_processor_id' RunAt="server">
<aw:MapValue value="100" replace="sidLblNotifyRule" />
<aw:MapValue value="200" replace="sidLblRoutingRule" />
<aw:MapValue value="500" replace="sidLblIncidentRule" />
<aw:MapValue value="700" replace="sidLblAutomationRule" />
</aw:Map>&nbsp
<aw:Label id="Label1" ItemDataSource="<%# Container.DataItem %>" ItemDataField="wuci_name" runat="server" />
</li>
</ItemTemplate>
</aw:repeater>
</UL>
</aw:Panel>

I'll keep looking, but hopefully this will help lead others to find it.

- Matt

lryker's picture
29
Jul
2009
0 Votes 0
Login to vote

Thanks to everyone so far. 

Thanks to everyone so far.  MBHarmon is getting close. He's correct: I want to be able to see the rules that actually fire when the incident is last saved as they are helpful in troubleshooting if/when Notify Rules work given certain conditions.   I appreciate MB and others for continuing to research how to hide the general set of rules on the worker view page so the view is not hogged by them...

Tenacious Geo's picture
29
Jul
2009
0 Votes 0
Login to vote

In times like these...

In times like these, I use the customization-dodging technique of, "we are putting on hold on any further customizations in view of the new version of the product being released this year." :) 

-Geo

bgreen's picture
29
Jul
2009
2 Votes +2
Login to vote

Two Modifications:

For viewing:

WorkItemView.ascx:  Find the line starting with <aw:Panel id="pnlNotifyRules"

add visible="false"

For editing:

subWorkItemEditGeneral.ascx:  Find the line starting with <aw:Layout id="loRules"

add visible="false"

Be sure to follow all best practices for file customizations (ie. don't change the built-in files, make a copy and leverage custom.config)

Hope this is what you're looking for!

lryker's picture
30
Jul
2009
0 Votes 0
Login to vote

Thank you

Well bgreen, you are the awesome dude.  I added the visible="false" to the aw:Panel id="pnlNotifyRules" in the WorkItemView.ascx file and the rules are no longer showing in the Incidents view.  (We already have a Custom file for the same so I simply modified it and documented it.)

I appreciate how everyone made suggestions until coming up with a viable solution.  Yes, I agree with George because he's right about the upcoming upgrade being a major change to what we're used to seeing anyway. But, it's nice to "fix" this issue for now because we won't be upgrading for as long as possible.