Allow order numbers to be incremental with prefix and suffix

[havenswift-hosting]

See feature request: https://features.cubecart.com/topic/incremental-order-numbers

I know that this says it is experimental but I believe it should be taken out until completed as it doesnt work correctly.

It is possible to place an order and the order numbering works OK, the order gets sent through to whichever gateway you want but returns with the old style order numbers and so order isnt updated from Pending to processing ; there is a mix of what order numbers have been used between the orders listing (incremental) and the transactions (old) and worse still the product code details seem to be lost from the order after payment - you can see an order with detail lines and prices but no product details

[abrookbanks]

is that the issue you are trying to resolve

Yes partially.

[PloughGuy]

Al, I'm all fired up! When do we get to see it. You mentioned 6.2 - is there a release date scheduled? Russ

[abrookbanks]

is there a release date scheduled

No I'm afraid not. I have extremely limited resources and the support help desk comes first over everything. A busy week on the help desk will mean no development. It's not very predictable aside from just after release which is always crazy busy. I don't have the revenue to hire dedicated staff.

[PloughGuy]

Fair enough. Are you thinking sooner rather than later? As in before June or after-ish.

[abrookbanks]

Before June unless we have any force majeure. I actually have a new born due in mid May so that might just about count as that. Haha. Also due to move into a new house at about the same time.

6.2 will only have a small amount of new features. Hopefully it will be ready in a few weeks.

[Dirty-Butter]

YES, that counts as a "force majeure". Time to burn the midnight oil now and get the upgrade done well before birthday, or expect to delay it until at least end of July would be my guess. Congrats on the upcoming birth!!! :)

[abrookbanks]

Thanks. It will be done before then. 😀

[PloughGuy]

Cripes, Al, what are you doing to yourself? Baby, schmaby - most people do that by accident. My congrats are for finding the strength to move house! Get yourself some nice big removalists. And whatever you do, don't watch "The Chain". You have enough stress already.

[Dirty-Butter]

Decided to install a 6.2.0 upgrade and see how this is working. Seems to be stable so far, but have not had time to really kick the tires. But I have a clarification - I would like to keep the yearly designation in orders, even if I have to do it manually. Obviously I would prefer automatic, but I understand that's a minor issue. So, I CAN change the prefix or suffix each year without any issue - just don't force old orders to change, right?

[PloughGuy]

To do it right, you have to stay sober enough to take the store offline just as Old Lang Syne starts, change the prefix, wait for the clock to stop bonging then get it back online to meet the rush of drunken revellers who get an extra high from shopping. A plug-in that automates this should be a nice little earner...

[Dirty-Butter]

I already use a piece of php code that automatically changes the year to keep the copyright date correct. It would be nice if something similar could be used within the admin code here.

[PloughGuy]

To do it properly, it has to be guaranteed correct. That means take the store down at 11:59:50, change the global containing the prefix, then start it up at 00:01. Should be possible to get that working in 10 months, you’d think.

[Dirty-Butter]

I have 3 old style order numbers on our trial store. I did NOT set to force old orders to the new pattern. I set the Increment Increase to 4027 (my last actual order number on live store). I did not put anything in the suffix box, but prefer to maintain my current style completely if possible. I expected to see the Preview to show the next order number to be 2018-PC-4028. But it's Previewed as 2018-PC-4031. Is that what it should do? It looks to me like if I had done that on our live store the preview would have shown the next order number as being up in the 8,000's????

[PloughGuy]

Of course, there is no need to do it at midnight, and no need to tak the store down. The first order to notice that the prefix does not match the year can fix it before it saves the order and activates the trigger. I expect the trigger itself would have to be updated, now I think about it.

[Dirty-Butter]

LOL you'll have it all figured out before the night is over

[PloughGuy]

Al has coded it so the new order number is the sum of the order_id and the offset that you enter. Every new order changes the result, so...

To guarantee that you get continuity, you should take the store down, find the highest order_id with phpMyAdmin, calculate what you need to do to it to get your next number, and that gives the offset. Set it, ensure your Bistromath is correct using the Preview function, then open the doors again.

It is entirely possible that in your case, it will be negative. Al, are negs allowed?

[PloughGuy]

It’s just after lunch here, so I’m firing on all 7 functioning cylinders.

[Dirty-Butter]

Well that's where my non-code view of things comes in handy to a programmer's brain. I was totally surprised by the preview result. Won't be an issue for people who don't already have a Sequential system in place. But there are folks on pre-v6 versions who would be using some kind of mod and the few who are using Chuggyskin's. THEY will be surprised. I'm getting off for the night. :)

[Dirty-Butter]

OK - I thought I was getting off. So I went to try a negative number. It lets me preview that BUT I can't get rid of the 4027 I had already saved - so I can Preview and see the result I want. But if I goof - which I initially did - I can't fix it. I should be able to go into the database and get rid of the 4027, but that's definitely something to work on tomorrow. I looked back through comments from you and Al, and I should have realized what was going to happen - but I was expecting it to just pick up the next number in the sequence and didn't notice it had skipped those 3. G'nite for me.

[abrookbanks]

I'll have a look to see if we can add macros to the prefix and suffix. It might be we can easily automate year/month/day/hour/min/sec. No promises though.

I can't bare to think of Rosemary working as the NYE clock chimes and I'm unlikely to be in a fit state to help out. Ha.

So, I CAN change the prefix or suffix each year without any issue - just don't force old orders to change, right?

Yes that's right.

are negs allowed?

Nope but I can't see any reason why they shouldn't be... I'll test it.

[PloughGuy]

Golly, macros! This is becoming deluxier every day... I really wish I had a use for all this yummy goodness. However everything I need is there, so yay team!

[abrookbanks]

Date Specifiers (or macros) work well!

[Dirty-Butter]

It's breaking the Preview for me. Zero seems to be what I need to put in the Increment Increase box to get the next consecutive order number to come up.

[abrookbanks]

Can you tell me the values that don't work? Appreciate your help. :)

[Dirty-Butter]

I tried with and without using the %Y. I saved each one, cleared Cache, and tried again. Neither one worked - just having the date mechanism available on the page seemed to be enough to mess it up. I tested before upgrading to the new code, since I had to edit the php config file to get rid of my original 4027. Yesterday's code works for me with zero Incremental Increase and preview works. Change the three files and Preview does not work.

[abrookbanks]

It works well for me. Not sure what to say without knowing the value of each field.

[Dirty-Butter]

OK - this is a pure test site. I'll try a new upgrade and see if that fixes it.

[Dirty-Butter]

Well I ended up wiping the whole site and installing again. I still can't get Preview to show anything - just blank info in it. So I made an Admin for you - will message the login info.

[abrookbanks]

Ok thanks.

[abrookbanks]

I'm actually really happy with this now. Closing for real work beta testing.... (before June).

Rosemary I'll check your store and apply any code changes to this branch if we need then.

Thanks Guys!!!

[PloughGuy]

So that implies you solves Dirty’s problem then?

You can’t just leave a bloke hangin’...

[abrookbanks]

No not at all. Please see my comment above. I'm waiting for access to check it. It will be reopened if needs be.

[Dirty-Butter]

Sorry - Ian helped me setup an FTP account for you, but I can't figure out how to make it work on CuteFTP. I misunderstood and thought you were satisfied it was MY error on the install. Will message you the ftp info as best I can.

[abrookbanks]

Yes please I'd like to test your store.

[abrookbanks]

Reopening because I just hit me that some mysql users might not be able to create triggers. A check needs to be made that the trigger set worked and revert if not.

[PloughGuy]

The alternative solution that I nicked from the interwebs earlier then benchmarked-and-tested (using a table and an atomic SQL statement) might help out here...

[PloughGuy]

The table can be created as part of the upgrade to 6.2.

[abrookbanks]

Sounds a bit over complicated when we can use a simple trigger. If the MySQL user doesn't have permission to read/write triggers then they can be granted in cPanel or by the hosting company.

[PloughGuy]

Don’t forget about the tail. A ytable with a visible SQL statement will possibly cause you - as in Al, proud father, occasional removalist and dedicated support engineer - less long term heartache than a trigger that operates out of sight and requires hosting partners to change their policies. (I can’t even get mine to activate storable SQL in phpMyAdmin.)

The trigger is a very neat solution, but ... Think about the long term. Is it going to generate blow-back? The table-and-atomic-statement solution is readily understood and has no dark corners. Is it possible that a cPanel update might delete the trigger? Is it possible that a user might delete the trigger? Then there is that whole weird initialisation calculus that you will have to document in a comprehensible way and then explain again and again and again. Yech!

A table with an easy-to-explain starting value and a simple test that asks “is there a bigger value than this?” to prevent dups might give you a quieter, easier life. Al, I raise this just because I care. Dirty Rosemary cares. We all care. You are like a god to us - we need you to be happy.

And I can’t help feeling that dark-side coding for a system that is often run by gifted amateurs on environments that change in unpredictable ways at the whim of the inexplicably self-confident high school drop-outs that hosting providers invariably employ is not going to deliver a happy Al in the long term.

Over...

PS: my store has been working moderately perfectly since 2009. Today, I get a 403 error when I try to update stock numbers. Yesterday, it worked. Some teenage mutant admin has been mucking about with the permissions again. And the “m” was a typo. This same problem, or similar, seems to happen every couple of years. It is the only problem I ever see.

PPS: My hosting folk just came back with a response 8 minutes after I reported the problem, at 8:00pm. “Looks like ModSecurity may be in play and interpreting it as a malicious change/attack. I've whitelisted this now.” Can’t fault the responsiveness - this fixed the problem. But I can fault the fault. Someone changed a rule somewhere, then I can’t update prices.

On 23 Feb 2018, at 7:57 pm, Al Brookbanks notifications@github.com wrote:

Sounds a bit over complicated when we can use a simple trigger. If the MySQL user doesn't have permission to read/write triggers then they can be granted in cPanel or by the hosting company.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[PloughGuy]

Question for Al: if the trigger disappears, does the order creation method detect it and fix it? If not, will the store start dropping (probably all) transactions because of duplicate keys?

[abrookbanks]

I literally can't see any reason at all why it would disappear. I suppose if you move hosting and you imported the database and the user didn't have permissions to create the trigger it would get lost. Thats not really a concern for CubeCart though.

Are you saying your hosting company doesn't allow you to use triggers?

[PloughGuy]

I expect they allow me to use triggers. I can do a science experiment to find out. Just saying that code in files and data in tables are relatively well understood by the general public, but triggers, not so much. I am merely exploring hardening options.

[abrookbanks]

I would have thought triggers would be the cleanest way and the merchant/developer shouldn't need to know anything about them as CubeCart handles it all for them. I do need to make it fool proof though and make sure the trigger was created successfully.

[PloughGuy]

Foolproof is the word. Evolution is making better fools every day...

[PloughGuy]

If the Lord does choose to taketh away the trigger, do we get a duo key error? I presume it will create one order with the default orderId then the second one will fail. Is that correct?

If the field is NOT NULL and the trigger vanishes, what happens? Can we detect this error and check that the trigger is OK then try again? This would be self-healing without a cost to each order other than the success check, which I hope already happens.

So something like “If the insert fails, recreate the trigger and try one more time.”

[abrookbanks]

I'll test it out and see. However once a trigger is made it should just stay. I can't see any reason for the lord to taketh it away.

[Dirty-Butter]

The Stability and performance improvement fixed my problem. THANKS Al!! And I was correct that using zero as the Increment Increase continues my existing sequence on the test site. It is definitely going to be an issue if the admin saves the page after preview and then realizes they want to save it again with a different value. I DO still know how to decode base64 config, wipe out a value, and then encode with what I want. Many would not. You do have that super powerful and potentially catastrophic section in maintenance that you're trusting everyday admins to respect - maybe you should consider giving admins a chance for a redo on the Increment Increase?

[abrookbanks]

Ok. Happy and closing again.

[PloughGuy]

Al said: I'll test it out and see. However once a trigger is made it should just stay. I can't see any reason for the lord to taketh it away.

He moves in mysterious ways, especially when it comes to computerised solutions, which he seems to find personally offensive. "I created the universe, life, DNA and evolution in seven days. It has worked a treat for over four thousand years. You guys have been working on IT for 70 years and look - I poke here and over it goes... Ha! Created in His own image indeed! Who came up with that one?"

If there is a way for it to go wrong, it will. David Mitchell as Shakespeare should have said: "A groat's-worth of hardening doth buy a guinea-worth of leisure." But he didn't. Still a good quote though.

[abrookbanks]

Thinking about this.. it should carry on working as it's still reliant on the traditional order I'd format. Then once the trigger is put back any empty fields will be populated. In the mean time some blank order numbers will be seen. Not a disaster. Any number of things can go wrong with CubeCart. Bridge will need to be crossed when it does.