Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.


  • Content Count

  • Joined

  • Last visited

  • Days Won


CHitzmann last won the day on April 15 2019

CHitzmann had the most liked content!

Community Reputation

6 Neutral
  1. @lesley So bad to see that nothing happens here. The Developer tried 3 times to get contact about a Partnership, but got no Answer from TB. That's very bad, because i think TB is missing such kind of module very bad. I got the latest TB Newsletter, where they want you to migrate to TB instead to PS 1.7 because the Sopport for PS 1.6 has ended. But all the Shops using any kind of Design Module will never be able to migrate to TB, since there is no such module on TB. And since the support has ended they'll not know how long it takes until the PS module-developer will also not support the 1.6 tree anymore, which can also make them stop working on TB in some future update. And on this Module it has allready become truth, because all new features are only in the 1.7 Version of this module and 1.6 and therefore TB will get only an old Version with most features missing. Here is a developer with a module - which could bring new stakeholders to TB - trying to Partnership with TB, but TB just don't answer... So Sad...
  2. @Gotabor Thank you, for this information. This Tool looks great. I'll have a look at it, and see, if it works on TB. But i think my boss will find it to expencive...
  3. hmm, bad News here. The developer tried to contact TB for a Partnership but didn't get an answer from them. Keep Finger crossed that they will do that in near Future.
  4. Good news (Maybe), i'm looking for such a design module, too. So i've contacted the developer of this PS Module: https://addons.prestashop.com/en/combinaisons-customization/22677-product-customization-designer-custom-product-design.html And he said he has contacted TB for a Partnership. So if everything works fine, we could see such a module in near Future on TB.
  5. @traumflug said in BUG in Stock Management when transfer between Stocks (fix included): You nailed it! Now I see it as well. Thanks a ton for your efforts! Not at all. :blush:
  6. The problem is not the isset or the syntax of the expression. The Problem is the semantic of it. In the original expression the semantic is: "look, if $productStockCriteria['usable'] exists and return the value of isset, if yes, or false otherwise. But what we really want is: "look, if $productStockCriteria['usable'] exists and return the value of $productStockCriteria['usable'], or false otherwise. Because in my example the $productStockCriteria['usable'] exist's, so isset will always be true. The original expression will only be false, if the $productStockCriteria['usable'] doesn't exists or if it's value is set to NULL. But the value of $productStockCriteria['usable'] is false. And that is what we really want to know. "You have the Answer and it is 42. But you don't have the right Question..." ;)
  7. Hello @Traumflug, yes i'm also wondering, but i can reproduce the error like mentioned above. With the line changed, it works well. But with the original line the error occurs. And you can see on debugging that it changes from false to true. I should say that the Server i'm on using PHP 7.1 May be, that it has changed there again. I will try to test it with a different Version of PHP. But a line with a complete statement makes it independent from what PHP-configuration you're using.... ;) The line, you mentioned isset($productStockCriteria['usable']) ? true : false also didn't work, because it is the same logic as the original one: isset is returning true in this case, even, if the 'usable' has the value false. So your statement also returns true, but it should be false. I added the following lines, just to make visible what is happening: Tools::dieOrLog('Test 1: '.Tools::jsonEncode(isset($productStockCriteria['usable'])), false); Tools::dieOrLog('Test 2: '.Tools::jsonEncode(isset($productStockCriteria['usable']) ? true : false), false); Tools::dieOrLog('Test 3: '.Tools::jsonEncode(isset($productStockCriteria['usable']) ? $productStockCriteria['usable'] : false), false); I've added these Lines just above the original return Statement. And this is the result: The 4th line is because the function is also called for the destination warehouse (where 'usable' is true). 'Test 1...' and 'Test 3... are not logged twice, because logging will skip them, if the same text is logged twice in the same x Seconds. I will try to redo the test with another Version of PHP. (Yes i could Google, if there has something changed in the behavior of isset between 5.x and 7.1, but this way it is more fun ;) ) Edit: Changed PHP Version to 5.6 and the result is the same.
  8. I found a Bug in the Advanced Stock Management when you try to transfer not-usable products. You can recreate this, if you do the following steps: * The Stock of WarhouseA is empty (Physical and usable) * Add Products to WarehouseA and set the "usable for sale" to false/no * Now use Transferstock in the Action-List of WarehouseA * set a quantity to transfer * Select usable in source to false/no (there is no usable Stock, so you want to move the physical) * Select WarhouseB as the destination * Finaly you select usable for destination to true/yes * click on transfer -> you will end up with this error: "It is not possible to transfer the specified quantity. No stock was transferred. " i found the line where i think it goes wrong in classes/stock/StockManager.php in Line 602: public function getPhysicalProductQuantities($productStockCriteria) { ... isset($productStockCriteria['usable']) ? : false ... } this changes the submitted "usable_from" from false to true because the variable exists (with a value of "false") and therefore isset will return true. This could be fixed in a simple way: public function getPhysicalProductQuantities($productStockCriteria) { ... isset($productStockCriteria['usable']) ? $productStockCriteria['usable'] : false ... } Now the statement not only checks, if 'usable' exists, it also uses the value of it and defaults to false, if it's missing.
  9. The solution is very easy. We add the event Object to the function, and see, if the actual Target is the trigger of this function and let the function do it things only once. This also keeps some time, because the function run only once (yes it will still be triggered many times, but only check the if...) Here is how the function looks like, now: ``` $collapse.on('show.bs.collapse', function(e) { if ($(this).is(e.target)) { var $target = $(this); var $targetAndParents = $target.parents().filter('.collapse').add($target); // Collapse all other menus which are not in the current tree $collapse.filter('.collapse.in').not($targetAndParents).collapse('hide'); // Add 'active' class to triggers which show this element $triggers.filter('[href="#' + $target.prop('id') + '"],' + '[data-target="#' + $target.prop('id') + '"]').parent().addClass('active'); } }); ```
  10. OK. The Problem is the following: The function $collapse.on('show.bs.collapse', function() {...} is called recursive starting at level 4 than 3 than 2 (Not 1, because this is always shown). The $target and $targetAndParents are renewed in each call. The $collapse is holding all menuitems. Than we use a filter on $collapse to see only items with subelements opened, remove all items from $targetAndParents from this list and hide all remaining elements on the list. In the first call of the function the $target is the level 4 and the parents level 3 and level 2, so this items are removed from the List. -> no Problem In the second call $target is level 3 and parents level 2 so they are removed from the list and level 4 has no child-elements, so this is also not on the list. -> no Problem And in the third call $target is level 2 and parents are empty so only level 2 is removed from the list and level 4 still has no child's and is also not on the list, but what about level 3? It is still on the list and therefore it get's closed. -> Here it is. Our Problem. Now we have the Problem. Now we can fix this...
  11. I'm getting closer. I commented out this Line: // $collapse.filter('.collapse.in').not($targetAndParents).collapse('hide'); Now all Levels are shown. But of course it now doesn't automatically close the Levels, if you select another level. But i think there is only a Problem with the $targetAndParents ...
  12. Thank you for confirming this. I was just wondering, if i was doing something wrong and no other one see this problem. Like i mentioned in my first post, the 4th Level is also showing up, if you open the category-page of an level 3 category. So it must be something in the Theme and i think it's something wrong in the JS Part of the blockcategories.tpl of the Theme. And i think the CSS Part for a single level should be dynamically added (especially the padding-left). Now you have to edit the CSS file for every level >3. i will have a look, if i can find, what's going wrong in the JS part, but any help with this will be welcome.
  13. Hello, i think i found a Bug. I'm having 4 Levels for my Categories, but when i click on the expand-button of level 3 the module doesn't show up the Level 4 items. It closes the Level 3 instead, so only level 1 and 2 are showing. I can than reopen level 3, but level 4 is never showed this way. But when i click on a link to a level 3 Category, the menu is showed correctly, with all 4 Levels opened. I edited the CSS for this module in the themes folder to add the styles for level 4. But i think there has to be something added in the JS part of this Module, too. But i cannot find, where the problem is... I'm using TB 1.0.3 (Migrated from a PS and the new community-theme-default. Module Settings are: * Show from root-category * max. depth: 4 * dynamic: yes * sort by position * sort ascending * Footerrows: 1
  • Create New...