"Having two or more users use the same login. That is having two users use the same account."
Would the way the email engine, approval server, flashboards history collection daemon, and other use the account "Remedy Application Service" be using this trick? The approval server seems to also stomp on these two scenarios: "Having someone login as someone else. That is having two users use the same account." "Submitting to another form and having filter workflow change the original. That is performing a modify which requires a license and you are just playing a trick to say it is a submit not a modify." The approval server and SLA (5.5/5.6) both submit records to the 'Application Pending' form, at which point the records are processed and perform various actions as 'Remedy Application Service' for all users who trigger events for those two products. Where do you draw the line for external applications? There are a lot of different scenarios where I honestly wouldn't know where to draw the line: - web application that shares a login to perform transactions to the arsystem - daemons that accept and process requests, whether directly or indirectly invoked by user interaction (e.g., signal, poll records, standalone process) For a more specific scenario, if I have an ARDBC plugin that needs to connect to Remedy to gather data to return to the vendor form, and it uses a shared account with a read license to retrieve the data, is this a violation? If so, how can I connect to the arserver as the user that initiated the GLE against the user form from the context of a plugin? Confused, Axton Grams On 7/18/07, Mueller, Doug <[EMAIL PROTECTED]> wrote:
Since there is often A LOT of confusion around this topic and then there are messages about being "creative", I thought I would jump in here. There have been a number of postings that discuss the strategy that the partner is very likely referring to -- and that strategy is perfectly legal and valid under your BMC license agreement. Submitter locked mode locks the value of the Submitter field AFTER SUBMISSION of the record. The value you enter, workflow, whatever you want can affect the value before submission. If in Submitter Locked mode, after submission, you can modify records where your login name matches the login name in the Submitter field. So, it really doesn't matter who types in the ticket or who hits the submit button. It is all about whose name is in the Submitter field when that record is saved to the database. Note I did not say when the button is pressed because there could be filter workflow that would change the Submitter field and that is perfectly legal if it is ON THE SUBMIT operation because the value has not been saved yet. It locks when it hits the database. Other scenarios Having someone login as someone else. That is having two users use the same account. Having two or more users use the same login. That is having two users use the same account. Submitting to another form and having filter workflow change the original. That is performing a modify which requires a license and you are just playing a trick to say it is a submit not a modify. Submitting to another form and having a person take that data and change the original. That is simply a manual version of the item above and is just playing a trick to say it is a submit not a modify. Are all violations of the BMC license agreement because they are all trying to work around the licensing rules of the system. The one scenario described above (that was described in at least two other postings) is indeed legal and valid and viable. NOTE: At your customers, each individual needs a login (not the company, each individual at that company). When submitting a ticket, that individual has their name put on the ticket and they are allowed to update it. If you have a login for the company and they have a license other than Restricted Read -- which would prevent any modifications under any conditions -- you are sharing a license across two people and that is a violation of the rules. Yes, even if they are not both logged in at the same time. It is sharing a license (and yes, a Read license is a license even though you get an unlimited number of them and there are no restrictions on connecting) and it is against the rules to share a license. So, this is a situation where the basic approach described is fine but it can be taken past the point of where it is OK and trigger a problem (if you shared a login across multiple people at a customer for example). As long as there is no license sharing in this scenario, it is perfectly legal and OK. I hope this note is useful, Doug Mueller -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Mike Wallick Sent: Wednesday, July 18, 2007 12:46 PM To: [email protected] Subject: Providing Read/Write Access Without Buying Licenses? I Doubt It Here's an interesting for for y'all. We have a very good and fairly long relationship with a BMC partner that we use for consulting/development/purchasing and, when the time comes in November or so, we will also be using them for support instead of BMC. First, a little background. We use Remedy Customer Support 5.6 with a not-too-customized version of the Customer Access Interface deployed through the mid-tier. The submitter mode on the AR server is locked, so that customers with account using read licenses can submit and work their own tickets through the web. However, we have many customers that insist on using the phone for the initial submission of an issue, and then want to work the ticket from then on through the web. You see where I'm going with this? The customer can't update tickets via the web if they were not the submitter, unless they have a fixed or floating license. Floating licenses are expensive, so we've been reluctant to go down that road. Our VP of support doesn't like the BMC partner that we've been using nearly full time for the past two years (they're GREAT, BTW), so now this VP is bringing in another consulting firm who claims that for $6400, they will solve the customer access interface licensing "problem" without purchasing any new licenses from BMC and also in a "BMC approved" manner. I call B.S. First, I find it hard to believe that BMC would allow some sort of scheme where you can get away with not buying licenses and still give your customer base read/write access to their tickets. Second, how else would one run a server in locked submitter mode, while still allowing customers to modify "their" tickets even if the ticket was submitted on their behalf by a tech support agent? The first thing that comes to mind would be to have a trigger or scheduled job or something at the database level change the submitter column to the customer's login name on insert of a new record. I seriously doubt that's a "BMC approved" solution. Perhaps this firm is going to suggest something like having the customer's "log in" but all the actual interaction with ARS will be proxied through a single user with a fixed license and all the necessary permissions. But even that seems like something that BMC might balk at. Thanks. Mike ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
