New SMUI feature "Copy input term & rule set"

[iris-stern]

Recently the idea for a new SMUI feature was popping up: The possibility to COPY all rules for an input term as a set. This would be very helpful while working with different tags/clients and with different languages. Search Managers would be able to copy complex rule sets and then rework them for another client as sometimes they might just need slightly different rules. It could be a button like "Copy input term & rule set" - getting to dropdowns where you can choose tags or language (where to copy/paste the input term to).

[renekrie]

Just a +1 for this feature as it has come up in a different search team as well.

[dobestler]

Another +1 from my side since we would like to work on a separate rules collection for quickly testing and tweaking rules in production (on a separate rewriter that can be triggered in PROD by the search manager manually). Once the rule fixed, we want to move it into the productive rules collection and deploy.

[dobestler]

As discussed with @pbartusch I propose a new UI Feature to move an item (rule management item or spelling item) to another rules collection. The new feature here is the "Move" action. Disable and Delete are only added to avoid a menu having only 1 action ;)

It does not yet fully solve the request from @iris-stern @renekrie but it could probably help the cause already and be a good starting point for further convenience extensions in the list item handling area. I could imagine a Copy action instead of move (should be almost for free then)

Any thoughts on this?

[renekrie]

Just wondering if a rule release workflow (see test vs. applied to the end user) is "what you really want" (tm) @dobestler. But I also like the feature as you proposed it. And we could probably have both "copy" and "move". I guess what remains to be done is implementing it ;-)

[dobestler]

Yes, exactly. The cheapest solution to establish our rule releasing workflow with current SMUI features is already in place but is a bit cumbersome because we need to copy /move items between collections. Paul and I have discussed more proper solutions that require a bit more conceptional thinking, especially regarding backwards compatibility. So I proposed to see it as a future step.

Having a simple move/copy feature would allow us to have several people managing rules at the same time with little risk of interference on the shared rule sets. After learning whether this process is helpful we could take the next steps into the direction of rules testing, tweaking and releasing workflows.

I'll try to find some time to implement the copy/move.

[dobestler]

@pbartusch It's almost ready. Which UI option do you prefer?

1. add a dropdown next to delete shortcut
   https://user-images.githubusercontent.com/11744444/220204470-c804ccd6-c9d9-4b73-9bd4-bf60666a91ca.mov

2. replace delete shortcut with dropdown
   https://user-images.githubusercontent.com/11744444/220204459-dfc23acf-bf71-466d-a998-681c1a99f7fd.mov

[epugh]

Very cool videos... Someday we probably need to have a multi select for when you need to get rid of lots of rules!

[pbartusch]

Hi @iris-stern and all others with operative search management experience, as copying of inputs & rules is realized - but with the focus of enabling draft rules rather than the mentioned multi tenant use case - I am interested in you perspective. My thoughts on that:

• By tenant tagging, we already provided a mechanism to develop slightly differing Search input & rule sets in a multi tenant environment - a long ago. I understand that this was only possible on the level of inputs, but I remember past discussions to also enable such selectivity for rules if necessary, which would less inflate the overall rule collection.
• Now there is a copy feature, but its not providing a way to directly set a tenant tag so far.

Some questions on the search manager experience:

• Rules collections are a general concept. But, so far I have only encountered the search language being represented by it. I can image that for fundamentally different tenants (assortment focus especially), it might also make sense to maintain a completely separated rules collection - even for the same language. What concepts do you know of that have been represented by the rules collection in SMUI (language = yes, other = fundamental different tenants? ...)
• What do you think is better in categories of "search manager UX", "long-term sustainability / understandability of the rules managed":
  (1) Use copies of inputs with different tenant definitions with slightly modified rules?
  (2) Use a unique input where tenant definitions are maintained explicity for the rule?
• Does the copy feature ( Feature/copy rules #124 ) in its current form also solve this issue (so that it can be closed)?