When you create an access token for a draft, that token is still accessible if the page revision is published then put into draft mode afterwards.
There should be an option to discard all active access tokens once a revision is published. This could be appropriate for a global setting as well as a per page setting.
1. Create a new node that has workflow options and can be placed into Draft or unpublished equivalent.
2. Create a new access token for that page.
3. View the link with the token to ensure it is working.
4. Publish the revision of the node.
5. Visit token link to ensure it does NOT work.
6. Create a new revision of the same node and place in Draft.
7. Visit token link. It should work and show the most recent revision.
Add either global or per-page option (or both) to discard all access tokens when the revision is published.
Would potentially add a checkbox/boolean field to the editing screen of a node, or the global configuration of the access_unpublished module.
| Comment | File | Size | Author |
|---|
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 #2
nesstheheroI have attached a patch that adds a global option to the settings form for Access Unpublished to clear tokens when a node is published.
Any tokens created while a node is unpublished will be deleted when that node is finally published.
Comment #3
kuldeepbarot commentedI feel there is no need to provide a configuration i.e. cleanup_tokens_on_publish checkbox, instead we can directly delete the tokens when a node is published. Updated the patch from #2.
Comment #5
generalredneckRe Kuldeepbarot's comment
I disagree. I feel there is a usecase where users will want to know the past tokens that were availible. Specifically with #3144610: Add a label to the access token and #3394195: Views integration added into the mix. Being given the option is more important.
That said, the current patch does not provide an update hook to upgrade the current configuration to the default of false that is being suggested which may cause a challenge.
lastly, we need some tests for the coverage here.
Comment #6
generalredneckComment #9
mably commentedSome improvements and fixes.
A functional test has been added.
Comment #10
generalredneckNeeds a quick reroll because of a recent merge. got a couple of conflicts because of the new update hook and what not.
Comment #11
mably commentedRebased and conflicts fixed.
Comment #12
generalredneckThis one is going into 1.x-dev