Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Item Code Restrictions removed
10-28-2015, 12:24 AM,
#1
Item Code Restrictions removed
Hi all,

I know what I am about to ask is not simple but we are trying to get a handle on why these restrictions exists and is it reasonable to go about removing them or at least understand why they exist so here goes:

1 - Remove the special characters restrictions:
(') single quote
(") double quote
(+) plus sign
(.) period
(&) amp percent
(\) slash
(>) greater than
(<) less than
( ) blank or space

2 - Expand the Item code to a size of 32 (varchar(32)) (no magic for choosing 32 just bigger than 20)

3 - updating to a more current version of PHP

4 - can webERP give us some indication if the above areas will be addressed in a near term future release.

your guidance and comments are welcomed and appreciated.
we have been using webERP just under a year and really like it.
but we need to decide if these restrictions can (or should be) removed.
since we are in USA we tend not to concern ourselves with language or currencies, but feel they are a very important piece with a growing world economy and necessary in the future.

Thanks again for a great software product,

Bill
Reply
10-28-2015, 02:44 AM,
#2
RE: Item Code Restrictions removed
Hi Bill, moving to a 32 character stock code is easy, just a case of making sure you get all the tables that reference that field, and changing the Stocks.php validation checks. For very large inventories (I have customers with > 1m part codes) it would have some performance impact but probably not significant. I would be interested to know why you need 32?

As far as I am aware there is no problem with PHP versions. I did the 5.3 changes myself a while back and since then there hasn't been great changes. I am currently running PHP 5.5.9-1ubuntu4.13 without an issues. Is your point that we keep backwards compatibility with older PHP versions?

As for the "illegal characters" that is a bigger issue. Some can just be got rid of as the don't make any difference. With the others it is possible but requires quite a lot of work.

Tim
Reply
10-28-2015, 04:26 AM, (This post was last modified: 10-28-2015, 04:39 AM by Bill Schlaerth.)
#3
RE: Item Code Restrictions removed
(10-28-2015, 02:44 AM)falkoner Wrote: Hi Bill, moving to a 32 character stock code is easy, just a case of making sure you get all the tables that reference that field, and changing the Stocks.php validation checks. For very large inventories (I have customers with > 1m part codes) it would have some performance impact but probably not significant. I would be interested to know why you need 32?

As far as I am aware there is no problem with PHP versions. I did the 5.3 changes myself a while back and since then there hasn't been great changes. I am currently running PHP 5.5.9-1ubuntu4.13 without an issues. Is your point that we keep backwards compatibility with older PHP versions?

As for the "illegal characters" that is a bigger issue. Some can just be got rid of as the don't make any difference. With the others it is possible but requires quite a lot of work.

Tim


Thanks Tim,

The 32 could be 50. I was thinking of a specific supplier that actually uses 32.
Myself I think all parts number should be assigned sequentially when they get past 12.

The PHP version was a concern only from the point of view that the installation instructions seems to indicate the recommendation is to stay at the earlier version (PHP 5.2.x?) We only have a couple installs and so we are not so concerned about backward as much as being able to take advantage of newer release capabilities. (Our Group is focused right now on Point Of Sale). We were also concerned about being able to obtain earlier releases of PHP and what we do if they became unavailable.

Two particular characters are . and (space). O-ring distributors and mfg's use . as part of their part numbers.
The guys that have large part numbers will use (space) to separate segments in their part numbers.

Most US fabricators will use ' and " to indicate ft or in (USA not metric) and . and (space). They also tend to have large part numbers due to dimensional indicators within their part numbers.

Do you know the ones that can be gotten rid of?

Thanks again,

Bill
Reply
10-28-2015, 08:08 AM,
#4
RE: Item Code Restrictions removed
Hi Bill, There were a lot of backward compatibility breaks between 5.2 and 5.3 but I know for sure I dealt with them at the time so the installation instructions need to be updated. I know of no reason why the most current PHP can't be used.

I will look at the illegal characters tomorrow, but I know that the ' and " characters are the two that are hardest to deal with.

The field size is easy to deal with, I can list the sql you need if you want?

Tim
Reply
10-28-2015, 11:20 AM,
#5
RE: Item Code Restrictions removed
Hi, Bill,

There is no php version constraint until the PHP 7 release according to my experience. If there is no mistake, current class defined style will not supported in PHP 7. So I think it what we should pay attention to.

Best regards!

Exson
Reply
10-29-2015, 05:59 AM,
#6
RE: Item Code Restrictions removed
Hi Tim,

We can probably locate the tables that would need to be updated.
We have gotten pretty good at reading the code and the data tables.

However, we would like to know what special characters could be used (like . and embedded space are really important).
I was reading up on PHP and found that the period is the concatenation character in PHP (hopefully it may be one we can still use in our item number).

Thanks,

Bill
Reply
10-29-2015, 09:06 PM,
#7
RE: Item Code Restrictions removed
Hi Bill, the . character is one that I don't think can be allowed. The problem is that if there is a dot (period) in a variable name then PHP replaces that with an _. This includes if the . is part of the index in a $POST or $GET array, so $_POST[1234.5678] will be replaced with $_POST[1234_5678]. There are I think still a number of places where the stock code is used as an index in the POST and GET arrays.
The (') single quote and (") double quote characters are as I have already said definitely out for now.
I am pretty sure that the (+) plus sign can be allowed, unless anyone knows any different??
The (&) amp, (>) greater than and the (<) less than can't be used at present but if all the variables passed in a URL are first passed into the urlencode() function then it appears to work fine for me. I do this in my branch and have debtorno, supplierid, and stockid all having them.
I would avoid the (\) backslash character
There should be no problem using a ( ) blank or space character though it would be strange I think to include it in a stock code.

Tim
Reply
10-29-2015, 11:36 PM,
#8
RE: Item Code Restrictions removed
Tim and Exson,

Thank you for the info. This has been very helpful.
We now can figure out what our next steps will be.

Bill
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)