-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Toggleable taxon #11287
[Feature] Toggleable taxon #11287
Conversation
mmenozzi
commented
Mar 25, 2020
•
edited
Loading
edited
Q | A |
---|---|
Branch? | master |
Bug fix? | no |
New feature? | yes |
BC breaks? | no? |
Deprecations? | no |
Related tickets | implement #8785 |
License | MIT |
- Enabled property
- Adjustment of repository methods to filter for enabled / maybe new methods to get all (also disabled)
- Showing in admin that a taxon is disabled in taxon create/update page
- Showing in admin that a taxon is disabled in products list page
Hi @pamil and @lchrusciel, I don't know why but this PR won't trigger the Travis CI build. Do you know why? Anyway it's ready for review. |
c776328
to
79d0a9d
Compare
Hi @pamil and @lchrusciel this PR is ready for review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the long response time @mmenozzi, it's a nice piece of code 👌
@@ -0,0 +1,29 @@ | |||
@homepage | |||
Feature: Viewing only enabled taxons in taxon menu | |||
In order to not access disabled taxons |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In order to browse only available categories
? We should think about the benefit or the Visitor/Customer. They do no think about disabled/enabled entities, but about the merch, they see in the shop :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, good point. I am ok in changing this only in the that specific line of the feature definition. Because i have some doubts in rewording this in the other parts of this feature: the taxon availability is not only related to the fact that it is enabled but even to the fact that it should be associated to the current channel. This features only test enabled/disabled taxon and not their belonging to a specific channel.
I don't know if i expressed correctly what i am thinking =)
Then I should see "Accessories Caps" and "Caps" in the menu | ||
And I should not see "Clothes", "T-Shirts", "Coats" and "Belts" in the menu | ||
|
||
@api |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Move this tag to the previous step (@ui @api
) and we save some lines 💃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of the step is sligthly different. Before i pushed the changes i had put them together in a single scenario but test failed at step 'Then I should see "Accessories Caps" and "Caps" in the menu' cause @ui and @api seems to fill the test attributes of the menu differently. For a parent category the @ui prints "[Parent name] [List of children names]", instead @api prints "[Parent name]". I don't think this should be solved with this PR.
Given the "Clothes" taxon is disabled | ||
And the "Belts" taxon is disabled | ||
When I check available taxons | ||
Then I should see "Accessories Caps" and "Caps" in the menu |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should use as little context-related words as possible (especially as we want to use this scenario both for UI and API). So maybe something like Then taxons "Accessories Caps" and "Caps" should be available
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I followed this file features/homepage/viewing_only_taxons_from_menu_taxon.feature and it uses "i should see"
Background: | ||
Given the store operates on a single channel in "United States" | ||
|
||
@ui |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also make it in API - check do we get 404 on some specific request
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A disabled taxon should still be available through API. Can you show some example for this case? Only a not existent taxon should lead to a 404 on API calls
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the shop perspective disabled taxon should not be available I suppose. However, the admin user should still have access to it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, you are totally right, dunno why i thought of it as an admin API
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @lchrusciel, did you mean that we should open a separate PR for the Sylius/ShopApiPlugin? Am I right?
Basically a PR to change here:
with something like:
$taxon = $this->taxonRepository->findOneBy(['code' => $code, 'enabled' => true]);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's split the problem into two parts.
First of all this repo: I just meant, that the current scenario makes sense and should be covered with UI. What (I think) @Zales0123 meant was about our new implementation of integration with Api Platform.
Secondly, Shop API is a totally different topic and can be covered after 1.8 release :)
features/product/viewing_products/accessing_disabled_taxon.feature
Outdated
Show resolved
Hide resolved
src/Sylius/Bundle/ShopBundle/Resources/views/Taxon/_horizontalMenu.html.twig
Outdated
Show resolved
Hide resolved
@@ -32,6 +33,10 @@ public function buildForm(FormBuilderInterface $builder, array $options): void | |||
'entry_type' => TaxonTranslationType::class, | |||
'label' => 'sylius.form.taxon.name', | |||
]) | |||
->add('enabled', CheckboxType::class, [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't it be true
as default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I followed what has been done for the enabled field in other entities and it is as this: no default value (as it true/checked as default) and required=>false. I am ok in changing this btw
@@ -56,6 +56,8 @@ | |||
</field> | |||
|
|||
<gedmo:tree type="nested" /> | |||
|
|||
<field name="enabled" column="enabled" type="boolean" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
redundant column
attribute
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But we have the practice to leave them in Core
src/Sylius/Bundle/TaxonomyBundle/Resources/translations/messages.en.yml
Outdated
Show resolved
Hide resolved
4896ed6
to
0c76f62
Compare
Hi @lchrusciel the build does not trigger continuous-integration/travis-ci/pr. It happened even few weeks ago and you resolved by closing and reopening, can you do the same? |
of course ;) |
8e2f97e
to
a2e5ab2
Compare
I made the requested changes and commented others. Ready to be reviewed again |
3f6d255
to
12b3e88
Compare
Hi guys @lchrusciel @pamil @Zales0123 , I made the requested changes and commented others. This PR is ready to be reviewed again. |
12b3e88
to
c51226e
Compare
Hi @lchrusciel @pamil @Zales0123, I resolved a conflict in this PR related to the inheritdoc removal. Let me know if there's something I can do to help. |
Background: | ||
Given the store operates on a single channel in "United States" | ||
|
||
@ui |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the shop perspective disabled taxon should not be available I suppose. However, the admin user should still have access to it
Thanks a lot, Manuele and Luca! 🎉 It was a lot of work but also quite a lot of waiting for us. Sorry about that. However, it is finally there and the whole community will take advantage of it after the next release ;) Also, can you apply changes from #11287 (comment) in separate PR? |
Thanks to you and the whole Sylius team! I'm happy that this feature will be available in Sylius 1.8. 🎉
Sure, will do it ASAP! |
Thank you guys! |
Great work, guys! Thank you! |