Axton, This feature was not intended for "integrations". Rather our vision is to set up some captive environments for users to do specific tasks. Tasks like: "I forgot my password, how do I reset it?" (among others)
The general thinking would be that we would create a second User record for person (with the same 'Login Name' but a different 'Password' and 'Group List'.) When such a "limited user" (Group List) logged in they would be "trapped" in the Home Page with only the fields/workflow that they should use for the captive environment that they requested. The goal was to create a new password that was tied to the right 'Group List' so that the user could only access that set of features with that password. However, if the user managed to spontaneously remember their password they would not be "stuck" in this environment because their "real" account is still intact. (and using AREA for it's password.) The "locked down" account would only be usable for a short period of time and then it would be auto removed even it the user had not manged to complete the given process. Yes all of this is in a planning/prototype stage, but with v7 being released and this feature being removed from the platform our work in v6.3 will likely be stopped. I guess it is back to the drawing board. We will likely be forced to build different 'Login Name' values for the user. Which will only add to the confusion for these processes/problems. But I still say it is a bad trend to see in any product. (Loss of a long standing feature.) There just seems that there must be some better implementation that would have left this feature intact. But my guess is that they think they are plugging some license "hole" by removing this feature. (Likely tied to $USER$ and Submitter mode locked.) But the real solution there would be to not continue to base $USER$ on the 'Login Name' string, but For anything in a Remedy form move to a GUID string related to the 'Login Name' that was authenticated as. And when AREA is in play, then use the 'Login Name' as the GUID. But also we get some control over the env when AREA is in play so that would not fix any license enforcement issues either. So... I am left with the conclusion that they changed something for some other reason, but it is just not clear to me what that would be. If this is a "Submitter mode locked" "problem", then I would even opt for a preference that a condition of "Submitter mode locked" be that the user be uniquely defined in _one of the many_ Remedy User forms. (Loss of that feature would not have impacted our designs and would have simply been a defensible "retraction of feature for licensing reasons".) But alas, I am just guessing and dreaming at this point. However, based on the lack of awareness that the community has about this feature (on and off the list) we may be the "corner case" that the Remedy engineers keep muttering about while they decide to break us in favor of where ever they want to push the platform to in the future. Sigh. I fear we might be the only ones in the ARS universe that care about the loss of this feature. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. Never ascribe to malice, that which can be explained by incompetence. On 5/13/06, Axton Grams <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carey Matthew Black wrote: > All, > > Am I the only one who is _very_ disappointed to read the following? > > Ref: Release-Notes-700-Web.pdf page: 18 > " > Unique user logins > In AR System 6.3, it was possible to have multiple users with the > same user name but different passwords log in at the same time. AR > System 7.0 does not allow multiple users with the same user name if > you use the User form for authentication. If, however, you use > external authentication, multiple users with the same user name can > log in only if they belong to the same groups. (In the cache, only one > session is created, and this session will be used for both users.) If > you are upgrading to AR System 7.0 from a 6.3 system where you allow > multiple users with the same user name but different passwords, the AR > System upgrade scripts will fail and will generate a message > suggesting that you correct the multiple user name problem. > " > > It sounds like they removed a very advanced (and very old) feature of > ARS in the name of performance and at the cost of backwards > compatibility. That is not a pattern that I would imagine most > customers would value. > I'm curious how you were using this feature. This is something I have never leveraged. When I needed an account that was shared (e.g., integrations), I used an admin account, where all programs used the same password. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFEZhgd2VxhVxhm8jIRAqvLAJ40pW4OsQyupxS6vX7bV1PlV4qgDgCfZN6h ZZKtj0lULZSprm+7DNzP1nI= =SrKK -----END PGP SIGNATURE-----
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
