Skip to content
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

Require variant category and supplier when creating new product variants [OFN-12666] #12690

Merged
merged 3 commits into from
Jul 31, 2024

Conversation

wandji20
Copy link
Contributor

@wandji20 wandji20 commented Jul 21, 2024

Use openfoodfoundation/wishlist#520 Flower Farms code in clokify

What? Why?

What should we test?

  • Updating products (variants) from old admin products table should work as before

  • Updating products (variants) from v3 admin products table should show errors if producer or category is not selected

  • Visit ... page.
    -

Release notes

Require variant category and supplier when creating new product variants

Changelog Category (reviewers may add a label for the release notes):

  • User facing changes
  • Technical changes only

Require variant category and supplier when creating new product variant

Dependencies

N/A

Documentation updates

N/A

@RachL
Copy link
Contributor

RachL commented Jul 24, 2024

@wandji20 hello! can you have a look at rebasing here? Many thanks for one more 🙏 You're on 🔥

Copy link
Member

@dacook dacook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for updating this Wandji.

I note that it might have been just as much effort to implement the new requirement in the old admin screen, instead of re-implementing the old behaviour. But I think it's ok 👍

Comment on lines +86 to +87
select supplier.name, from: 'Producer'
select taxon.name, from: 'Category'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't actually test the newly added requirements, that the producer and category dropdowns were blank at the beginning.
That would have been nice, but I think this is still ok.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes here were to fix failing specs
I agree it will be nice to check when the variant category and producer values are blank

placeholder_value: t('admin.products_v3.filters.search_for_producers')))
include_blank: t('admin.products_v3.filters.select_producer'),
placeholder_value: t('admin.products_v3.filters.select_producer')))
= error_message_on variant, :supplier
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, thanks for adding error_message_on. It probably should have been added in the beginning.

Comment on lines +129 to +131
# Set new variant category to same as last product variant category to keep compactibility with deleted variant callback to set new variant category
newVariantId = $scope.nextVariantId();
newVariantCategoryId = product.variants[product.variants.length - 1]?.category_id
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why we are doing this, It would make more sense to set the category to blank same as the new screen. I am not sure what you are referring to when you say "to keep compactibility with deleted variant callback to set new variant category"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure what you are referring to when you say "to keep compactibility with deleted variant callback to set new variant category"

I think he means to maintain the existing behaviour on the old screen. So there would be no apparent change when using the old screen. But as you say,

It would make more sense to set the category to blank same as the new screen

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the old screen the supplier is set to blank, I think it would be better to have a consistent behaviour.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😮 Oh, so this change makes it worse than before? In that case we need to do better.
Wandji would it be hard to make the old screen behave like the new one?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot, @dacook and @rioug for identifying this one.
I noticed that the columns preference default for the category column in old screens have visible: false
Not so sure why we have this by default but I will gladly appreciate your input on this again.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, that's a good point Wandji. If the Category column is hidden by default, it's not intuitive for the user to choose it.
I just tried it out and can see what you mean.

If your PR ensures the old screen maintains the existing behaviour, I think it's ok to proceed as it is. It adds a bit of technical debt, but that's ok because we're planning to remove the old screen later, once the transition to the new screen is complete.

Is that ok with you Gaetan?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that ok with you Gaetan?

Yeah that's fine, if we get complaint we can always tell them to use the new screen 😉

@mkllnk mkllnk added the user facing changes Thes pull requests affect the user experience label Jul 30, 2024
Copy link
Collaborator

@rioug rioug left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good ! thanks @wandji20 🙏

@filipefurtad0 filipefurtad0 self-assigned this Jul 31, 2024
@filipefurtad0 filipefurtad0 added the pr-staged-au staging.openfoodnetwork.org.au label Jul 31, 2024
@filipefurtad0
Copy link
Contributor

Hey @wandji20 ,

Thanks for another PR 🙏

Before this change, we can see that:

  1. a producer is pre-selected
  2. The first product category s pre-selected on the list.

image

After staging the PR:

  1. We can see that no produced is pre-selected
  2. We can see that no product category is pre-selected

image

Attempting to save a variant without this information correctly triggers the warning, for these fields:

image

Looking great! Merging.

@filipefurtad0 filipefurtad0 merged commit 6c21454 into openfoodfoundation:master Jul 31, 2024
52 checks passed
@dacook dacook removed the pr-staged-au staging.openfoodnetwork.org.au label Jul 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
user facing changes Thes pull requests affect the user experience
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

Creating a new variant is selecting the first producer and first category of the dropdown
6 participants