Closed (fixed)
Project:
Content locking (anti-concurrent editing)
Version:
8.x-1.x-dev
Component:
Code
Priority:
Minor
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
22 Jan 2018 at 15:29 UTC
Updated:
20 Feb 2018 at 08:59 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #2
Jaber ME commentedSolution :
Comment #3
Jaber ME commentedComment #4
chr.fritschThank you, it's a very nice feature request.
When we do this, we should try to provide this action for every entity type that is using content lock.
I will try to cook something up.
Comment #5
chr.fritschHere it's implementation with a deriver.
I would like to here @kfritsche feedback on this, especially on the release part.
Comment #7
chr.fritschLets give this another push.
Comment #9
chr.fritschTests are passing. I think this is good to go.
Comment #10
kfritscheWas reviewing it while it got committed :/
But still
Missing entity type id.
Same issue as described in #2938092: Ajax lock not created due to strict permission checks, but would be fine for now.
Not sure about this. Would it make sense to check configs here, if type is lockable?
General note regarding caching. I'm unsure about this, but maybe just to think about it. Are Actions cached? Views are cached could this run into problems?
Comment #11
kfritscheComment #12
chr.fritschThanks for reviewing. I try to be more patient next time 😆
1. Nice find
3. I think thats fine. That doesn't mean that there are actions. That just means that these entity types could possibly used for the action.
The general problem is, that the view is most of the times cached. So the view says the entity is still locked, but it isn't. We have this problem with the "Break lock" operation as well. So thats not a problem of actions.
Comment #14
chr.fritschFixed 1.