View Query does not respect pager offset

Moving this to 1.1.x since 1.2.x is not a thing, this branch shouldn't exist. So, support requests got into 1.1.x, while feature requests and bug reports go into 2.0.x

Now to your question. I've removed the word "delete" from the title of the issue, since it's about the offset in a views query only.

When I look into views and set an offset to one of them, I see the query in the preview area and that contains the offset. So, I would expect the result set to only contain the items that are received from that query, i.e. not those below the offset. But I haven't tried with ECA yet. Could you probably create a simplified example with a simple view and an ECA model that only receives the entities from that view and outputs their ID? If that doesn't work as expected, please export that ECA model and upload it here, so that we can review.

Apologies for the typos. Long dev day.

I set up a new test run using nodes to keep things simple, as follows:

Node Type: Test
Added field: field_test

Created View
Type: Content > Test
added field: field_test
set pager show all, offset 1
no relationships, filters or conditional fields to keep things clean

Created Model
as above. Export file attached.
enabled model

Test run:
1) added Test content
Results: content deleted
not expected

2) disabled model
added test content
content created as expected
reenabled model
added 2nd test content
new content created as expected
previous content deleted as expected

Have you tested my suggestion in #3? Debugging works best if you go through step by step. So, instead of deleting something, you want to make sure first, that the view returns the expected result. So instead of deleting the token loadtestview, you should loop through all items in that list and print their IDs. That way you find out what you get from the view.

There is even a problem with using the "Entity: delete" action and forwarding the loadtestview to that, because that token is not an entity, it's a list of entities. That's not supposed to be working in any way.

Another potential issue could be, that when Drupal core dispatches the "Entity: insert" event, that the cache may not have been refreshed at that point so that the view may not yet get the proper result.

But all of that can be determined with the step by step approach described above.

I came up with an if/else conditional workaround that checked whether or not the item was new or preexisting, and set the delete on preexisting items only.

If I can carve a few minutes out of my weekend, I'll try your suggestions and will post my results, for future reference.

Ok, finally found some time to do some testing.

TEST 1:

Create content: test1

View:
Content type: test
Fields: ID, test field

Update model to:

Event: create test content
Load: view query
Load: entity from view
Message: show view [token:node:id]

Created content: test2

Expected message to show id of content test1
Results: Correct

--------------

Test 2:

Update model:
Added Delete Loaded Entity

Created content: test3

Expected content test1 to be deleted
Results: correct
>>>obeys offset

--------------

Test 3:

Update Model:
Remove Load Entity
Set Delete on the View
Set Message to show View token

created content: test4

Results: deleted all items in list except test4
Message shows deleted item
>>obeys offset

----------

Test 4:

Disabled model
Added content: test5, test6, test7
Reenabled model
Added content: test8

Results: deleted all items in list except text8
Message shows all items in View queue, obeys offset

------------

Test 5:

Reloaded model posted earlier. Model is:

Event: create content Test
Load: View Query
Delete Entity: Loaded View Token
Message

Added content: test 9

Results: deleted test 9, left remaining content
Message: token is empty

-----------------------------------------------

So, this is weird because Test 3 and Test 5 should have had the same results, since the models are substantially the same. Am uploading the Test 3 model here for comparison.

The views in the model process_lgag7wm and bpmn_io-process_lgag7wm2 are different.

If I create a number of test or 1_test nodes, then the view from the latest model shows the correct nodes in the preview where the other one doesn't.

The 2 differences I found:

• The broken view has only the test field in the field list, but not the ID
• The broken view has an extra filter compared to the other one

I haven't tested further, but from that it's clear that this has nothing to do with ECA.

OK, so running actions on a Views Query requires the entity ID to be placed in the view. Just restating this for future folk who might run into the problem.

No, that's not correct. Forget about ECA, you can disable ECA if you want to reproduce this. Just open the view in the views UI and run "Preview" on the view there. You can see that the one without the IDs is not returning any result. So, what broken is the view's configuration, nothing to do with ECA whatsoever.

Hmm, so now I'm confused because it was deleting all the items in the Views array.

But for test case 5 you reported "token is empty". In any event, you have a working model, and the other one contains a view which doesn't return any results. I think, that's as much as I can help with.

Yes, the token was empty, but it still deleted the array. I'm still not clear how this can be the case.

But, as you say, I have a working model, so I'll have to experiment some other time.