[ENG-7873] CLONE - SPAM - When Hamming a Spammed user, preprints and registrations remain private

[antkryt]

Purpose

fix was_public state when flag spam

Changes

• correct check if node was public when flag_spam
• use earliest confirm/flag spam log to check if node was public instead of the latest one

---

• fix TypeError when check archiving status for stuck registrations (not related to ticket ENG-7873, but it's just one line permissible_addons = set(permissible_addons), so no additional testing is required)

QA Notes

I couldn't reproduce this issue via UI, but combination confirm_spam() -> flag_spam() -> ... breaks this feature. I'm not sure if it's exactly what's happening in our case, but since flag_spam() is used with automatic spam checks during node/preprint updates, it's quite possible.

Documentation

Side Effects

Ticket

https://openscience.atlassian.net/browse/ENG-7873

[brianjgeiger]

Okay, this is a tricky one. Could you add a test that:

1. Spams a public project
2. Hams the project to make it public
3. Make the project private
4. Spam the private project
5. Ham the project

The project should be private when that's all done.

[antkryt]

Note that logging the privacy change is crucial in this context.
For example the following test will fail:

  def test_multiple_privacy_changing(self, project):
        project.set_privacy('public')
        assert project.is_public

        project.confirm_spam()
        assert not project.is_public

        project.confirm_ham()
        assert project.is_public

        project.set_privacy('private', log=False)  # log=True is crucial!!!
        assert not project.is_public

        project.confirm_spam()
        assert not project.is_public

        project.confirm_ham()
        assert not project.is_public

There are some suspicious places where the privacy log is not created:

• osf.io/api/preprints/serializers.py

  Line 453 in f7737c5

  preprint.set_privacy('public', log=False, save=True, ignore_permission=ignore_permission)

• osf.io/osf/models/preprint.py

  Line 886 in f7737c5

  self.set_privacy('public', log=False, save=False, **kwargs)

• osf.io/osf/models/registrations.py

  Line 587 in f7737c5

  node.set_privacy(

• osf.io/osf/models/registrations.py

  Line 840 in f7737c5

  node.set_privacy('public', auth=None, log=False)

• osf.io/osf/models/sanctions.py

  Line 888 in f7737c5

  registration.set_privacy('public', auth=None, log=False)

These seem like edge cases, so I left them untouched as I don't know whether this behavior is expected

[brianjgeiger]

@antkryt So the spam system doesn't set a flag when the object is spammed to say whether it was public before the spamming happened or not? It's all just relying on logs?

[antkryt]

@brianjgeiger correct. It was proposed and implemented in this ticket to fix multiple spam scenario. Some alternatives:

1. add was_public_at_spam (or something) field to AbstractNode and Preprint models (easy to implement , but hard to extend/modify in the future)
2. add something like SpamContext table with OneToOne relationship (harder to implement, but easy to extend)

We can implement was_public_at_spam separately for AbstractNode and Preprint, and just check something like "if the status isn’t initial, pending, or rejected, then it was public" as you suggested in the ticket comment section. That technically works, but honestly feels a bit unreliable and messy.
A much better approach (and not just for spam) would be to have a dynamic is_public property. That way we can centralize the logic "if it’s not initial, pending, or rejected, then it’s public" and reuse it anywhere we need to know if something was or can be public

[brianjgeiger]

@antkryt Okay, I've been chatting with Product on the Jira ticket, and we're going to make this so that, regardless of logs or whatever, if a preprint is not in initial, pending, or rejected moderation state, then it should be public. We'll want to make sure that preprints that were never made public don't suddenly become public, but I think they'll be in the initial state, even if they aren't moderated. But please verify that.

[antkryt]

@brianjgeiger what about registrations and projects?

[brianjgeiger]

@antkryt Projects we'll continue to do the way we are. We might do registrations similarly to preprints, but there are more states and it's not as urgent, so let's leave registrations for the moment and revisit that if necessary later.