Jump to content

Incremental Order ID removing all old order IDs


Russell Hurst

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

 

 

Link to comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...