When opening a form in a workspace, that workspace should be active until the form is submitted.
- Activate a workspace and open the node add form
- Open a new tab and activate another workspace
- Go back to the initial tab, fill and submit the form
- Observe that the node is tracked by the second workspace instead of the initial one
Ensure that the initially active workspace is persisted through the entity lifecycle of the form.
Review.
Nope.
N/A
API addition with BC:
- A new optional argument ($persist = TRUE) is added to WorkspaceManagerInterface::setActiveWorkspace()
N/A
N/A
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | 3525642-nr-bot.txt | 91 bytes | needs-review-queue-bot |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
amateescu commentedComment #4
smustgrave commentedAppears to have a number of test failures.
Comment #5
amateescu commentedNo more test failures :)
Comment #6
smustgrave commentedThink there may have been a rebase issue?
Comment #7
amateescu commented@smustgrave, not sure why you think so, the MR was applying just fine. Merged the latest 11.x though just in case.
Comment #8
smustgrave commentedSo why are the changes to the gitlab file, link module, file discovery, etc needed?
Like its merging in other stuff
Comment #11
amateescu commentedOops, I wasn't looking at the changes tab. Not sure what happened there but I couldn't do anything with that branch so I opened a new MR instead.
Comment #12
pameeela commentedComment #13
smustgrave commentedSince this is an API change probably needs a CR
Comment #14
amateescu commentedAdded a CR.
Comment #15
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #16
amateescu commentedComment #17
smustgrave commentedCRs seem fine to me. Believe all feedback has been addressed here
Comment #20
catchWhen I look at this I keep thinking there must be a better way to do it, but I don't think one exists - e.g. it might be good if we could make ajax_page_state extensible and put other things in there that always have to be passed around to various AJAX requests but it's not. Given this is self-contained in the workspaces module, going to go ahead and commit this and if a centralised way shows up later we can eventually convert over to that.
Committed/pushed to 11.x and cherry-picked to 11.2.x, thanks!