Mark, Yes....various versions of Remedy have had permissions issues over the years and each successive version of Remedy tries to plug holes that the previous version had...so, in your situation, sending to an email address instead of a user, you must make sure that the permission 'trail' is clear....here is the trail you must make sure is available to the 'Public' group
Application - If the form in question is part of an application, you must make sure that the public has access to it Form - The form must have public permission Record - Each record has row level restrictions, so you must allow all users access to the row in question Field - To access the data, the user must obviously have access to it I saw the post from Todd regarding ignoring form permissions....but I'm not sure I personally like that option....simply stated, if you are sending information out of a Remedy system to an 'unknown' user, then that unknown user should have access to all of that data to be able to get at it....if you don't have Public permission at the Application/Form/Record/Field levels, then the unknown user doesn't have access to the data, and shouldn't be able to get access to it through email.... I know that's a tough stance, but that's the stance that Remedy must make to ensure that truly sensitive information isn't accidentally leaked. On Thu, Jan 11, 2018 at 11:17 AM, Mike Galat <[email protected]> wrote: > Hi RJ – > > > > First, this all worked in 8.1.02. We are also going against custom forms, > and the fields that we are using in the notifications typically have a > permission of “Public:View”. > > > > As far as sending to email addresses, the email addresses may or may not > be defined to the User form. We have our own custom people form which > contains our profiles. In that form is the email address. If we are > sending to a requester, that person is likely not a Remedy login user (read > no User form record, etc.) According to the BMC 9.1 documentation, this > should be supported. See: > > > > https://docs.bmc.com/docs/ars91/en/creating-a-notify-action-609072091.html > > > > User notification method email: > > Email — The notification is sent to the specified recipients by email. You > can identify BMC Remedy AR System server recipients by their BMC Remedy AR > System user or group names, [or enter email addresses to notify any > recipient inside or outside of BMC Remedy AR System server]. > > > > Thanks, > > > > *From:* ARSList [mailto:[email protected]] *On Behalf Of *LJ > LongWing > *Sent:* Thursday, January 11, 2018 12:39 > *To:* ARSList > *Subject:* Re: 9.1.x Notify Action Delivery Mechanism > > > > Mike, > > Who is the recipient of the notification, is it a user name (value in > login id field), or is it an email address? If it's an email address, are > there more than one users in the system with that email address. If there > are, if you send it to an email of a user with only one user account > associated....does that user have permissions to the fields in question? > > > > On Thu, Jan 11, 2018 at 10:30 AM, Mike Galat <[email protected]> > wrote: > > Hi – > > > > We are currently working toward upgrading from AR System 8.1.02 to > 9.1.03/(or 9.1.04). Currently our lab server is running 9.1.03. We are > running into an issue with the Notify action in Filters. > > > > The Notify Delivery Mechanism allows a few values: > > > > 1: Alert > > 2: Email > > 3: User Profile Default > > 99: Cross-Reference > > > > For cross reference, you can then pass an integer value to define the > delivery mechanism at runtime: > > > > 0: No delivery > > 1: Alert > > 2: Email > > 3: User Profile Default > > > > By running some filter logging we have narrowed down the types of delivery > mechanisms that succeed/fail. It has been our experience with 9.1 that > using: > > > > · User Profile Default (3) or Cross-Reference, with User Profile > Default (99/dynamic 3) SUCCEEDS. > > · Email (2) or Cross-Reference, with Email (99/dynamic 2) works > FAILS. > > > > What I mean by succeeds or fails is this: > > > > When it succeeds, the email goes out, and all variables in the subject and > text get expanded. So suppose I send a notification for a ticket being > opened User Profile Default, and the subject has > > $Ticket #$ has been opened at $Create Date/Time$ > > The email’s subject will contain: > > “PT-123456 - has been opened at - 1/1/2018 09:04:36 AM” > > > > When it fails, the email goes out, and all variables in the subject and > text DO NOT get expanded. So suppose I send the same notification for a > ticket being opened, using Email delivery mechanism, and the subject has > > $Ticket #$ has been opened at $Create Date/Time$ > > The email’s subject will contain: > > “ - has been opened at - “ > > > > Has anyone else experienced this behavior. If so, were you able to fix > it, and how? Note: changing the notify mechanism is not an option, as we > use email in many filters. All of this works just fine for us in Remedy > 8.1.02 > > > > Thanks! > > > > Mike Galat > > > > > > > -- > ARSList mailing list > [email protected] > https://mailman.rrr.se/cgi/listinfo/arslist > > > > -- > ARSList mailing list > [email protected] > https://mailman.rrr.se/cgi/listinfo/arslist > >
-- ARSList mailing list [email protected] https://mailman.rrr.se/cgi/listinfo/arslist
