[MSHOP-134] Activation of shop configuration fails - all the subnodes are removed from the public instance Created: 09/Apr/14 Updated: 09/Mar/15 Resolved: 09/Feb/15 |
|
| Status: | Closed |
| Project: | Magnolia Shop (closed) |
| Component/s: | None |
| Affects Version/s: | 1.1.4 |
| Fix Version/s: | 1.1.5 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Edgar Vonk | Assignee: | Robert Šiška |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Magnolia Enterprise 4.5.18, Java 7, Tomcat 7 |
||
| Attachments: |
|
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: |
| Description |
|
This happens for our client's Magnolia instance but also for a clean Magnolia Enterprise 4.5.18 with the Shop Module 1.1.4 with samples installed. For our client it happens on their production environment whenever they need to change their shop configuration. This results in an incomplete shop configuration on their website and thus in a non-functional web shop which we need to fix by hand very rapidly when this happens. Not nice. Use case with Magnolia Shop sample data:
So you end up with a shop on the public instance without any tax categories, currencies, etc. As a workaround we then very quickly export all of these configurations by hand (XML Export) and import them again on the public instance. I had a quick look but cannot figure out what the issue is. The shop node data types are all registered correctly as far as I can see. It must have something to do with the Magnolia data module workflow in relation to the shop module. I have not tested it but I suspect the issue also occurs on Magnolia 5. |
| Comments |
| Comment by Jaroslav Simak [ 11/Apr/14 ] |
|
Hi, Problem is in wrong configuration of itemTypes in the shop tree configuration. There are two options that solves the issue:
I am going to fix the issue by adding itemTypes from option #2 so it corresponds with 5.x shop behaviour. |
| Comment by Edgar Vonk [ 14/Apr/14 ] |
|
Thanks! This fixes the issue. I used option 2 as well. However there is another (I think related) issue: the 'Activate' menu items in the shop menus for the currencies, tax categories etc are now no longer available (since this fix). Can you have a look at this as well? I reproduced this with a clean Magnolia 4.5.18 with the latest 1.1.5-SNAPSHOT shop module with the fixes for this issue. |
| Comment by Edgar Vonk [ 14/Apr/14 ] |
|
I created a new JIRA issue for this: |
| Comment by Jaroslav Simak [ 25/Apr/14 ] |
|
Reopened because of |
| Comment by Jaroslav Simak [ 25/Apr/14 ] |
|
After some investigation i discovered that info.magnolia.module.data.trees.GenericDataAdminTreeConfig adds conditions (written in javascript) that disables activation on item types defined in the tree. The solution here would be to create separate tree for currencies, tax categories, price categories, etc. Note: |
| Comment by Robert Šiška [ 05/Jan/15 ] |
|
The behavior is now correct (see The |
| Comment by Jaroslav Simak [ 16/Jan/15 ] |
|
Can you please post link to git in comments? I wasn't able to find fix for this issue on any branch in shop repo. |
| Comment by Robert Šiška [ 09/Feb/15 ] |
|
Issue was fixed by your commit implementing the 2nd option (registering item types and subtypes). The issue was reopened only because of inability to activate subitems, which is a) issued separately as |