Something to think about....maybe this IS fixed I have quite often seen things that when I upgrade, it breaks my system, then as I investigate my problem, I find that in previous versions, proper permissions weren't being applied to my data, and the upgrade fixed a permissions hole that I was inadvertently using. So the upgrade in my situations, while breaking my workflow, actually made my workflow work correctly, and I needed to update the permissions on the system to allow my workflow to work the way I intended it (not knowing I was taking advantage of a security hole)...
So...in this situation, if previous versions allowed field data to go out in an email, when the recipient couldn't be verified to have proper permission to that data....then the upgrade is properly enforcing permissions, and there is NOT going to be a backwards slide in that security model... That is exactly what I hear being discussed here...so I suspect if your notifications are sending out information that the recipient can't be verified has permission to, you can likely fully expect it to not be sent out :) On Thu, Jun 20, 2013 at 10:24 AM, Pruitt, Christopher (Bank of America Account) <[email protected]> wrote: > I truly hope they get this fixed before we make that upgrade next year to > 8.1. It would be a pain to have to rewrite all of our notification filters. > > Christopher Pruitt > Business Consulting III > Remedy Developer > BMC Certified Administrator: BMC Remedy AR System 7.6.04 > HP Enterprises Services > [email protected] > www.hp.com > > > > Confidentiality Notice: This message and any files transmitted with it are > intended for the sole use of the entity or individual to whom it is > addressed, and may contain information that is confidential, privileged, > and exempt from disclosure under applicable law. If you are not the > intended addressee for this e-mail, you are hereby notified that any > copying, distribution, or dissemination of this e-mail is strictly > prohibited. If you have received this e-mail in error, please immediately > destroy, erase, or discard this message. Please notify the sender > immediately by return e-mail if you have received this e-mail by mistake. > > -----Original Message----- > From: Action Request System discussion list(ARSList) [mailto: > [email protected]] On Behalf Of Misi Mladoniczky > Sent: Thursday, June 20, 2013 7:50 AM > To: [email protected] > Subject: Re: Any clue why this is happening? > > Hi, > > I have an active defect SW00447306 that is related to the Body (Message > Text). > > Inline fields there did not need to be public before version 8.0, but the > behavior apparently changed in version 8.0... > > The selected fields (not inline) has always been subject to permissions, > but inline fields did not. > > An inline field is somthing you put in the text such as: > Dear $Name$, you request $Short Description$ has been registered. > > This may be slightly off topic, but when investigating this I also found > out that you can now set filters to run with the permissions of the User as > well as the System. This would be ideal to handle this situation where we > as developers can choose which setting to use for the Notify-filter. > Unfortunately this had no effect on the Notify filter at all... > > Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) > > Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11/12): > * RRR|License - Not enough Remedy licenses? Save money by optimizing. > * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. > Find these products, and many free tools and utilities, at http://rrr.se. > > > Hello All, > > > > I want to thank for everyone for the always valuable input and indeed > > it was a permission issue. I have no idea why the fields in the > > subject needs public view but the fields in the message body do not. > > In any case, we have it working now. Now the task of identifying the > > hundreds of filters and their forms that have this condition begins. Oh > what fun that will be. > > > > Again thank all of you, > > > > Christopher Pruitt > > Business Consulting III > > Remedy Developer > > BMC Certified Administrator: BMC Remedy AR System 7.6.04 HP > > Enterprises Services [email protected] > > www.hp.com<http://www.hp.com/> [HP_logo] > > > > > > Confidentiality Notice: This message and any files transmitted with it > are > > intended for the sole use of the entity or individual to whom it is > addressed, > > and may contain information that is confidential, privileged, and exempt > from > > disclosure under applicable law. If you are not the intended addressee > for > > this e-mail, you are hereby notified that any copying, distribution, or > > dissemination of this e-mail is strictly prohibited. If you have > received this > > e-mail in error, please immediately destroy, erase, or discard this > message. > > Please notify the sender immediately by return e-mail if you have > received > > this e-mail by mistake. > > > > From: Action Request System discussion list(ARSList) > > [mailto:[email protected]] On Behalf Of David Durling > > Sent: Wednesday, June 19, 2013 9:53 PM > > To: [email protected] > > Subject: Re: Any clue why this is happening? > > > > ** > > I also had an issue with field references not showing on the first > update I > > made to some notification actions after moving workflow from 6.0 to 7.5 > > (patch5,6,or 7 - not sure which) - they worked until I went in to modify > them. > > One suspect was a field ending with a plus sign (+), which I think was > worked > > around by setting its value to temp field and using that in the notice > > instead. > > > > In regards to the subject line question, it does seem like some > permission > > issue there had to be worked around too - if you don't want to change the > > actual field to have Public permissions, use a temp field that has Public > > permissions & set it to the value & use that temp field in the subject > line. > > I think that worked for me. > > > > This is partially from memory, may not be exactly accurate. > > > > David Durling > > University of Georgia > > > > > > From: Action Request System discussion list(ARSList) > > [mailto:[email protected]] On Behalf Of Susan Palmer > > Sent: Wednesday, June 19, 2013 10:12 PM > > To: [email protected]<mailto:[email protected]> > > Subject: Re: Any clue why this is happening? > > > > ** > > I actually have a similar problem on v7.5. It's on a notification email > > filter that has been working for several versions and worked fine for at > least > > 1-2 years on v7.5. Then I went into the filter, probably the first > change > > since we went to v7.5, and made an adjustment to the body and since then > the > > Case ID will not show the value in the Subject line, only the $Ticket ID$ > > field label. I've tried everything I can think of, including > recreation, and > > it continues to do. I'm not touching the other similar filters I have! > > We're in the process of upgrading to v8.1 so I won't be spending more > time on > > it and I'm curious to see how the new version does it. > > These are filters that were initially created in v5 10 years ago. > > > > Susan > > > > On Wed, Jun 19, 2013 at 4:51 PM, Pruitt, Christopher (Bank of America > Account) > > <[email protected]<mailto:[email protected]>> wrote: > > ** > > Hello All, > > > > We are stumped on an issue and was hoping someone on the list would have > an > > idea why this would be occurring after upgrading from ARS version 7.1 > with it > > works on to 7.6.04 and now it does not. This is regarding Emails being > > generated in a Filter by Notify contain a Subject line without variable > > substitution. The message text is working okay. Any ideas? > > > > Here are the details: > > > > The filter has the following set on it. > > > > Set Fields From: Task_Details_Join > > > > Set Field If > > 'Task_Details_Request_ID' = $Request ID$ > > > > If No Requests Match: Set Fields to $NULL$ > > If Multiple Requests Match: Use First Matching Request > > > > Field Mapping: > > Field Name Value > > TempChar1 $OrderNumber$ > > TempChar2 $LineTicketNumber$ > > > > Notify > > Notify Text: Order $TempChar1$, ticket number $TempChar2$, the task > $Full Task > > Name$ has been assigned to you as of $TIMESTAMP$. > > User Name: $Assigned_To_Email_Address$ > > Priority: 0 > > Mechanism: Email > > Subject: Order $TempChar1$ / # $TempChar2$ has a Task that has been > assigned > > to you. > > > > Include Fields: None > > > > When we check the filter log it shows > > Checking " TASK-GA710-NOTAFY- New_Assignee`!" (710) > >> --> Passed -- perform actions > >> 0: Set Fields > >> TempChar1 (600000000) = ORDER_TIC-00000971986 > >> TempChar2 (600000001) = 8097764-001<tel:8097764-001> > >> 1: Notify > >> Priority: 0 Mechanism: Email To: > >> [email protected]<mailto:[email protected]> > >> Order ORDER_TIC-00000971986, ticket number > >> 8097764-001<tel:8097764-001>, the task 1.00.01 Add Line Item > >> has been assigned to you as of 06/19/13 13:34:31. > >> Order / # has a Task that has been assigned to you. > > > > So you can see the Text did set the variables: > > > > TempChar1 and TempChar2 but the same two variables are also used on the > > Subject line and it just sets blank values in there. We have triple > checked to > > make sure that the same variables are used in the Set Fields, Notify > Subject > > and Notify Text and yet the Subject line the variables are NULL. > > > > Any clues as to why this is occurring after an upgrade? > > > > Our environment: > > Server OS: HP-UX B.11.31 > > Database: Oracle 10.2.0.4.0 - 64bi > > Database Client Libraries: Oracle 11.2.0 > > Remedy ARS version: 7.6.04 SP4 201209051922 > > > > > > Christopher Pruitt > > Business Consulting III > > Remedy Developer > > BMC Certified Administrator: BMC Remedy AR System 7.6.04 > > HP Enterprises Services > > [email protected]<mailto:[email protected]> > > www.hp.com<http://www.hp.com/> > > > > > > > > Confidentiality Notice: This message and any files transmitted with it > are > > intended for the sole use of the entity or individual to whom it is > addressed, > > and may contain information that is confidential, privileged, and exempt > from > > disclosure under applicable law. If you are not the intended addressee > for > > this e-mail, you are hereby notified that any copying, distribution, or > > dissemination of this e-mail is strictly prohibited. If you have > received this > > e-mail in error, please immediately destroy, erase, or discard this > message. > > Please notify the sender immediately by return e-mail if you have > received > > this e-mail by mistake. > > > > > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > > "Where the Answers Are, and have been for 20 years" > > > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
