Once upon a time the CAN-DO function was "misused" to do string pattern checking. A sort of poor man's regex. But, it was documented so that made it ok.
CAN-DO always had unpredictable results as it was never designed for pattern checking. Thankfully it's simple to change it to LOOKUP. All you need is to swap the arguments around.
I believe that it got "broken" because of multi-tenant.
can-do was *always* only to be used for security checking. Despite
what the docs and examples say ;)
On 4 March 2014 11:21, Ham wrote:
> CAN-DO Function
> Thread created by Ham
> Once upon a time the CAN-DO function was "misused" to do string pattern
> checking. A sort of poor man's regex. But, it was documented so that made it
> From 10.2 documetation:
> CAN-DO ( id-list [ , string ] )
> In addition to performing security checks, you can use the CAN-DO function
> for looking up any
> value in a comma-separated list. For example, the following procedure
> searches your PROPATH
> for your DLC directory:
> MESSAGE "The DLC directory " +
> (IF CAN-DO(PROPATH, OS-GETENV("DLC")) THEN "is" ELSE "is NOT") +
> " in your PROPATH.".
> That same example code now breaks in V11!
> Where can-do function has been "declassed" as only security checking against
> CAN-DO ( id-pattern-list [ , userid ] )
> Did anyone notice?
> Got angry?
> Had to write it's own CAN-DO function?
> Please share!
> Stop receiving emails on this subject.
> Flag this post as spam/abuse.
"The bitterness of poor quality remains long after the sweetness of
low price is forgotten"
Follow dot.r on http://twitter.com/DotRlimited
CAN-DO functions as it always has with one exception and that is the addition of @ to the list of magic characters ... as Julian says, to support multi-tenant. Unfortunately, that has uncovered some abusive uses. :)
Not exactly :-(
CAN-DO had also simple pattern checking, including special characters like ! for NOT and * as a wildcard. Lookup won't do that. I'm afraid a User defined function is the only way to replace CAN-DO with something that also works in V11.
Fair enough. Although, technically, you should have been using your own function in earlier releases too ;)
I agree with Wim, Etienne, et al. Progress customers got burned by bad documentation in 10.x and earlier. If the Progress documentation for a function says, release after release, that you can use it for a use-case other than userid permission-checking then that's a valid use case, full stop.
Code that implements such use cases is not "abusive". It is not code that "should not" have been written. That's just insulting.
Product documentation tells you what a feature does and, hopefully, how it should or should not be used. If it tells you you can do something with a function then you can. Later versions of the documentation can't just come along later and effectively say "why did you do that, idiot?"
I don't care what is said to the contrary in KB articles or in the archives of the PEG. As a customer I expect documentation to be correct and complete, every bit as much as I expect the code to be so. If I read the docs and they say "you can do x" then I take it as read that I can do x. If someone (Progress?) expects me to second-guess everything I read in the docs and verify it against other sources then (a) my productivity will plummet and (b) the docs are almost useless.
Also, the PEG, wonderful as it is, is not a Progress support channel. It is unknown and invisible to many (most?) Progress customers, it is e-mail only and not searchable, and even if a given user subscribes to a channel where such discussions may happen they only see future conversations, not those in the past where, for instance, informal guidance may have been given about the "right" uses for CAN-DO. There's a lot of good stuff on the PEG. But as a medium for exchanging ideas and viewpoints, it also contains a lot of stuff that is just plain wrong (including some posts of my own).
Well, Rob, you have much higher expectations of the documentation than I do. It is full of bad practice because the examples are there to show what the language features does, not how to use in in best practice. And, while the @ clearly surprised a number of people, I have been seeing discussions about the misuse of CAN-DO for the majority of my 30 years experience in ABL.
Works fine in 11.2.1 (on Vista x64), even reporting 'is' when silly enough to actually set DLC as an environment variable.