The spec was not really testing the order of users appearing on the
page. It's also a UX detail only visible to super admins which is not
important to test. So I'm not investing time to fix it.
The locale config is set in application.rb from environment variables
already. We don't need to repeat that logic in test.rb. And because it
was outdated, the language switcher was actually broken in the test
environment. We did have an English selector for the fallback `en` even
though we were already displaying English as en_TST. And after
switchting to Spanish, we could switch back because en_TST was not in
the available locales.
I now fixed the test with the right assumption and the config to solve
the problem.
I considered a few ways to do this. Cloned products are done with MutationObserver but it doesn't quite sit right with me. A dedicated controller for newly added rows would provide a good general solution. But do we want yet another controller? I'm not sure. This works and is pretty simple (although it requires a quick loop over _every_ form element.. let's see if we can avoid that.)
There are two types of linked variant associations: source and target, so we need to keep the name there.
But when cloning a variant and retaining a link as source, we will prefer the general term 'linked variant'. Hopefully this name works well.
Preload the allow list once in the controller. This controller was initially set up to avoid instance variables, and pass variables explicitly to the template. That's a good principle, but in practice we have a growing list of variables passed down the chain to multiple partials which is getting cumbersome. I think instance variables have their place after all.
The permission is effectively the feature toggle. Users can choose to use it, but shouldn't expect it all to work perfectly yet.
When it's considered full featured, we just need to update the translation. Hm... I hope that's not too painful.🤞
For now, we will only be able to create sourced variant from variants that are visible to us (variants that we manage)
In a later commit I will hide the option if you can't use it
There's no "COPY OF" product in the spec setup, so we don't need to check that it's not there. (unless maybe we added that to the product factory, but it seems unlikely).
Also we can use helper method.
These tests are about browsing products, not performing actions.
Well, ok there's one about updating, which should probably go in the update file. But hey this is better than before.
And admittedly the "Actions" file covers three different things, not just the actions menu. shrug.
Enterprise have access to the internal payment method by default.
The access is handled at the application level so we don't have to
manage database links.
This assertion was confusing me. It was quite complex and the only thing
it was asserting was the placeholder via a CSS selector. I don't think
it's worth keeping.
The custom helper was adding a PowerTip which replaced the title
attribute with its own display. I removed the PowerTip and use a simple
title attribute. This should have several benefits:
- Capybara can find the link by the title.
- Screenreaders should be able read the title.
- Browser can show the title in the best position.
- Using the browser feature is more consistent and efficient.
Adds functionality to retain tag filters applied in the admin product interface after bulk updates. Updates controller parameters to include tags_name_in, adds hidden fields for tag persistence in the view, and includes specs to verify filter state retention across update operations.
