Closed (fixed)
Project:
Commerce Core
Version:
8.x-2.x-dev
Component:
Store
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
31 Jan 2019 at 20:32 UTC
Updated:
2 Nov 2021 at 17:49 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
davps commentedPatch contains next changes:
Comment #3
mglaman+1 at a quick review this looks correct. I'm at Decoupled Days and will try to find time to sit down and test it. I was going to add a "Needs tests" tag, but I'm not sure if it is worth testing these fields.
Comment #4
lisastreeter commentedI wasn't able to apply the patch because of EntityDuplicateFormTrait. This is a simple reroll to fix that. No other changes.
Comment #5
lisastreeter commentedAttempted to run database updates. Got an infinite loop with message: Division by zero commerce_store.post_update.php:98
I'm working on a fresh commerce install that does not have any stores yet. Update hook needs to account for that possibility to avoid division by zero bug.
Comment #6
mkalkbrennerI re-rolled the patch and removed redundant functions.
Comment #7
mkalkbrennerSorry, I made a mistake. Next try ...
Comment #8
mkalkbrennerThe patch is essential to get commerce stores to work better with default_content_deploy.
Comment #9
jsacksick commentedWriting a post update function to set the initial created/changed value isn't necessary. Also, not 100% sure this is what we want (i.e setting the created/changed timestamps to the current time).
But base field definitions have a way to specify the initial value (using the setInitialValue() method).
Comment #10
mkalkbrennerI just re-rolled the patch as it solves our problems;-)
How can we get a decision about the default value for existing stores?
Comment #11
mkalkbrennerI removed to post updates like discussed with jsacksick on slack.
Comment #12
mkalkbrennerAs discussed in slack, the StoreForm is now "similar" to ProductForm.
I also tested the form with existing stores after applying this patch. No exceptions and the created and changed dates will be set to request time on the first save. If you add the dates to a view they will simply have an empty value until the first modification happens.
Comment #13
jsacksick commentedIt kind of feels weird to show the current date as "last saved" when the changed timestamp is empty.
Also, probably make sense to have a 2 columns layout, just like products.
Note that
$this->timeis available.And, making the created editabledoesn't really make sense IMO.
Comment #14
jsacksick commentedComment #15
jsacksick commentedThe attached patch no longer exposes the "created" time in the form. Also, made the changes mentioned in #13.
The store form has now a secondary region, containing the tax settings, the supported countries.
I also added the store owner, below the last saved timestamp. And add the top of the region, the default store shows "Default store", see the screenshot below:
Comment #16
jsacksick commentedCommitted!
Comment #18
mkalkbrennerThanks. I like the new UI.