clean-up-last-modifier-id: Don't delete guest users

[reinhardt]

Ref syslabcom/scrum#2372

[ale-rt]

It seems to me we are removing code that we would like to have just because it is hard to fix it.
It does not feel right.

I have no idea if we are removing a feature which is requested by some customer.

I am wondering if adding a session.flush() or even an intermediate commit after changing the last_modifier_id might help.

@pilz do you know if somebody cares?

@reinhardt , I am available to pair on this to find a solution that keeps the feature.

[reinhardt]

I have no idea if we are removing a feature which is requested by some customer.

No. The main point is to fix a database state that makes trouble with the guest user cleanup script (#2155). If we don't delete the users here, they will be deleted there: https://github.com/euphorie/osha.oira/blob/main/src/osha/oira/sql_scripts.py#L55

FTR OSHA has some concern about guest users created by bots, but this is about guest sessions that were taken over by registered users and therefore cannot have been created by bots.

I am wondering if adding a session.flush() or even an intermediate commit after changing the last_modifier_id might help.

I had no succes with that, as mentioned in https://github.com/syslabcom/scrum/issues/2372#issuecomment-2180401673

I have doubts whether it's worth spending more time on this. What do you think @pilz? (So far it's about half a day.)

[ale-rt]

I have doubts whether it's worth spending more time on this. What do you think @pilz? (So far it's about half a day.)

I came up with #751

IMO the knowledge acquired it is worth the amount of time spent.

[ale-rt]

I am pretty sure this will never do anything because of plone protect. In #751 I had to add an explicit commit to make it pass the csrf protection.

[reinhardt]

Does plone.protect also protect postgresql?

In any case, closing this in favour of #751.