Well the comma problem should have gone by now, I don't think that is
in the illegal characters check but I may be wrong?
As for the full stop that only causes a problem when the stock code is
used as an index in the POST array. This is easily altered, and our
customers have been able to use a full stop in the stock code for a
while. It's really pretty miserable that we still prevent the users
from having what is a commonly used character in the stock code.
As for other ASCII characters I agree that users should be able to use
whatever characters they want. I have been doing some test and
automatically creating thousands of items (actually I have been using
suppliers but the principles hold for Stock Items as well) using
random ASCII characters and seeing what happens. There is a bit of
work needed to properly filter all the data, but am close to being
able to completely eliminate the ContainsIllegalCharacters() function
On 27 August 2011 12:27, Craig White <craigwhite@...> wrote:
> On Sat, 2011-08-27 at 10:56 +0100, Tim Schofield wrote:
>> The change required to accept a . In a stock code is very little, we
>> did it some time ago but Phil didn't want it :-(
>> On 27 Aug 2011 03:36, "Craig White" <craigwhite@...> wrote:
>> > On Fri, 2011-08-26 at 11:10 +0100, Tim Schofield wrote:
>> >> Hi,
>> >> The use of a "." in stock codes is something I come across a lot,
>> >> I do think it makes more sense to change the code to work correctly
>> >> rather than hack around the problem by simply blocking codes using
>> >> that character. The technique used by Peter in the file he linked
>> >> is the best solution IMHO as it allows the user to have the stock
>> >> codes they require.
>> >> Thanks
>> >> Tim
>> >> On 26 August 2011 10:57, Phil Daintree <phil@...>
>> >> > Hi Benjamin,
>> >> >
>> >> > Well unfortunately, it is not possible to use "." in stock codes
>> >> > This was trapped previously and the code to trap it was removed
>> in error
>> >> > a little while back.
>> >> >
>> >> > However, these are now trapped again in stocks so it is no longer
>> >> > possible to create such codes. You should upgrade and change the
>> >> > codes using Z_ChangeStockCode.php
>> > ----
>> > 2 1/2 years ago...
>> > and 2 years ago I had to deal with it...
>> > Sure would be nice if we had a coding style that ensured this didn't
>> > happen and then yes, you could dispense with the checks but until
>> > then...
> I think the point I was trying to make was that 2 1/2 years ago it was a
> problem, it's still a problem and evidently will be a problem 2 1/2
> years from now too.
> In my case, it wasn't periods in stock codes, it was commas and it
> seemed to manifest itself as SQL insert errors when processing GRN's so
> it was particularly insidious because orders were generated for some
> time before the problem became obvious.
> I think that we're in agreement that this is an artificial solution
> There's really no valid reason why any valid ascii character can't be
> included in a stock code. The whole concept of trapping them was because
> the SQL insert statements and PHP print statements didn't properly
> escape them so the fix was to simply block people from using them. One
> would hope that a mature code base would eventually audit their code for
> style that incorporates proper escaping techniques that not only
> eliminates the need to trap for these characters but also prevents xss.
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> web-ERP-users mailing list
WebERP Africa Ltd