Allow recipes to be re-"installed" (re-applied) inside PB

Swapping over to the Drupal CMS tag, I only just realised we are using both.

I'm not 100% sure this is a *blocker*, more of a goal, but happy to leave the tag for encouragement :)

I don't really think this is a stable release blocker. It's pretty easy to implement, so we should get it done, but it need not be a stable blocker. Or even a beta blocker for Project Browser.

Adding target tag so we can track these nice to haves.

So currently if we apply a recipe the status card shows installed but as soon as we refresh the page the select button appears again.I am not sure if that's the desired behaviour or we want something like once the recipe is installed a re-install button should appear appear on the card(which i think is a better approach and a more user friendly approach).
Marking it NR to get others opinions on this.

as soon as we refresh the page the select button appears again

I've never seen this behaviour, for me, it shows as 'Installed' always after it is applied.

Looks like this needs to be re-synced with HEAD.

Oh, we can also completely remove the event subscriber stuff from RecipeActivator since we're no longer tracking it.

Although...hmmm. Do we want to remove the tracking? It's true we're not using it anywhere, but it might be nice to show folks that they already applied a recipe. That would take some UX work, though, and the current way PB works dictates that if it's installed, it's not re-installable.

So maybe the right approach here is to leave it as-is and work out the proper UX (in a follow-up) to show some kind of "already applied" badge to recipes that have been applied.

RE #9:- I still see what i mentioned in #8.I'll try to record a video and upload.In the mean time if anyone else can also verify the current state.

RE #9 Please see the recording.

On the latest 2.0.x as of right now (46ab2a2) - I can go to recipes tab, apply a recipe, it shows "installed ✔️" - then I reload the page, and it still says installed.

In an IDEAL world, it would be nice to actually record a LOG of when recipes were applied and be able to show the user that it has already been applied at such and such time/date. However, I'm not yet sure what the UI for that would be.

I THINK my personal belief is that given the option of what we have now (disallowing reinstall) or allowing users to re-apply (and they simply must track themselves if they've applied a recipe before or not), I THINK I would choose the latter. But I'm happy to be outvoted by other UX folks' opinions.

Test cases that need to happen here:

1. A recipe with no input should trigger a batch job and redirect back to the page we were on.
2. A recipe with input should show a form, and once that form is submitted, it should trigger a batch job and redirect back to the page we were on. If there are validation errors, the form should always refresh until those are resolved.

phenaproxima → changed the visibility of the branch 3489729-allow-recipes-to to hidden.

Wow, this one is turning out to be really effing hard to pull off.

I'm going to back off and try to think of an approach that will actually work.

Needs tests, but I found an approach that makes this work without major UI behavior changes and extensive refactoring.

Long story short: allow follow-up tasks to take advantage of the use-ajax class.

Test written - I think we're good here.

Initial manual testing here seems to imply this is working well. Small pieces of feedback:

(1) the dropbutton with only one action in it looks janky. Not sure if we leave the carat, or shrink the space, or what. But something.

(2) having an issue with 'Drupal2.$dialog is not defined' or something similar. I have seen this in other MRs so I don't think it's related to this issue. But I've seen it enough that it should have a FU.

Saving credit

Merged !779 🎉

Automatically closed - issue fixed for 2 weeks with no activity.