Jump to content

Incremental Order ID removing all old order IDs


Recommended Posts

I thought I might have a try at using incremental order IDs as it would save a little bit of office admin time. When I put in my chosen prefix and test it all is good. When I save the settings though all previous orders have their IDs removed, screenshot attached.

I don't want to renumber all the previous orders so did not check that box, another screenshot attached.

Does anyone have any idea what happened?

incrementalordernumbers.jpg.9f65cd0d1d762b4bada095126560ea83.jpg

incremental settings.png

 

 

Edited by Russell Hurst
Link to post
Share on other sites

I have used Incremental all the way back to when it was  a Semper Fi extension. This did not happen to me at any point during upgrades and eventual inclusion in CC and subsequent improvements. Please check your actual cpanel database and see if they are still there. If so, I suspect it's something wrong with the admin coding - maybe in the skin?? If not, I sure hope you have a backup!

Link to post
Share on other sites

I don't understand why my install of Incremental is behaving properly when Bsmither says the OP's is normal for this version of CC. I just double checked, and all my cpanel CubeCart_order_summary entires show all information - cart_order_ID AND custom_OID AND customer_id.

My CC Admin page shows the traditional order number for the oldest sales, but not the customer's name - contrary to what OP shows here. But my install was originally version 3, so that may explain that - probably something I did wrong on an upgrade somewhere along the way.

Link to post
Share on other sites

Could be that if your entire Cubecart_order_summary table has a value in the 'custom_oid' column, then it could have carried over from CC3, or maybe the option to "Apply format to all past orders" was checked.

But, start with an early CC6 install, make some sales, then upgrade and switch to using a custom order code, and make more sales. The database will have in the CubeCart_order_summary table, 'custom_oid' column, either the custom order code or possibly null - depending.

When viewing the list of orders in admin, the code does not cause a fallback to displaying the traditional order number if the custom code is null. (I complained about this to the programmers.)

 

Link to post
Share on other sites
13 hours ago, Tony said:

Please hide the names of your customers, this is a breach of GDPR.

Not from my understanding of the guidance given by the Information Commissioner's Office https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/key-definitions/what-is-personal-data/

Your suggestion that the names be hidden is a good one though. I'm nervous of clicking the Moderation Action in case I delete the whole topic, so not sure how to go about it.

Link to post
Share on other sites

So, in follow up all is good now with the order IDs however another issue has cropped up;

With the incremental numbering enabled I am no longer able to do a partial search by order number, either using the old or new ID numbers.

Before enabling it was possible, is this a known glitch?

Link to post
Share on other sites

It is a known 'glitch' -- and perhaps it is an unintentional choice in coding.

The code was changed from before Incremental Order ID was installed that the standard format was "LIKE" searchable, to after Incremental Order ID was installed that when using Incremental format the search is literal while if using standard format the search is "LIKE" searchable.

Let's look closer at the test:

if (isset($_GET['search']['order_number']) && !empty($_GET['search']['order_number'])) {
    if ($GLOBALS['config']->get('config', 'oid_mode')=='i') {
        $where[$GLOBALS['config']->get('config', 'oid_col')] = $_GET['search']['order_number'];
    } else {
        $where['cart_order_id'] = '~'.$_GET['search']['order_number'];
    }
}

From my point of view, this test structure is not needed. A simple:

$where[$GLOBALS['config']->get('config', 'oid_col')] = $_GET['search']['order_number'];

Should be sufficient. The config setting identifies which of the two columns in CubeCart_order_summary will be used to find the search term. (Unfortunately, this does not search both columns - such that should 'custom_oid' be null, the query might still pick up the search term in 'cart_order_id'.)

Not to mention that I think there should be a squiggle prepended to the search term so that the term is "LIKE" searchable.

Link to post
Share on other sites
On 4/23/2021 at 9:07 PM, bsmither said:

From my point of view, this test structure is not needed. A simple:

$where[$GLOBALS['config']->get('config', 'oid_col')] = $_GET['search']['order_number'];

 

I think the potential issue here is that the config value may not be set.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...