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.
I think I was just following convention from existing relationships. Perhaps you could argue that a variant is affected by the links added/removed.. but we never look at updated_at so really there's no point at all.
I tried to avoid it but rubocop made me move it. I think maybe it will need to go into a concern or service class later, but hopefully it's ok here for now.
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.
Co-authored-by: dacook <4188088+dacook@users.noreply.github.com>
Thanks co-pilot for sending me in the right direction.
Would this be neater as a has_and_belongs_to_many? Maybe but I will try to keep moving.
Tried using the rails generator, but as usual it was a waste of time becuase it doesn't handle unusual cases.
I found more good guidance from that stackoverflow post:
> why are you worrying about your indexes? Build your app!
Something's not right in the model, see next commit.
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.
