fix task and view sync might be buggy

[MyPyDavid]

Description

Related issue: #1360

The incremental signal handling left out some behavior for specific cases in the the synchronization of the projects views or tasks.
For example, when the last catalog of a view is removed it should be available to all catalogs (-> needs to be added to all projects). When a catalog is then added to same view (to an empty views.catalogs), it needs to be added to projects with that catalog and potential removed from other projects.
Now, the architecture has been changed into checking the whole state for all projects on each signal. The incremental design got more complex and need many specific queries.

Test cases were added that explicitly test for the proper behavior.

• implementation and tests for catalogs

  • view.catalogs
  • task.catalogs

• implementation and tests for groups

  • view.groups
  • task.groups

• implementation and tests for sites

  • view.sites
  • task.sites

• implementation and tests for view.available

• implementation and tests for task.available

• handle sync views when project.catalog changes

• handle sync tasks when project.catalog changes

• management script sync_projects

  • to sync views on all projects
  • to sync tasks on all projects

PS
I tried out the copilot agent from the codespaces for this (but first suggestion was already a hallucination)

[MyPyDavid]

rebased to 2.3.2

[MyPyDavid]

this is maybe still needs a design decision.
Currently, when a project has a catalog that is unavailable it will be disregarded for syncing.
Is this a typical use-case or does the sync needs to go over all applicable projects anyway? @m6121

[jochenklar]

Ok, testes with a lot of projects. And also with the feature disabled. Great work!

[jochenklar]

Instead of the loop you can just use instance.projects.remove(*to_remove) here.

[jochenklar]

Forget the two last messages. I think you can merge now.

[MyPyDavid]

I forgot to add the management script to initialize the synced state with, maybe with a for loop over the views/tasks?

[jochenklar]

Again awesome work! I wonder why you use self.stdout.write instread of print?.

[jochenklar]

This should include --show.

[jochenklar]

I would format it a bit different:

Project "Test" [id=1]:
- Tasks:
  - http://example.com/terms/tasks/null
  - http://example.com/terms/tasks/text_equal_test
- Views:
  - http://example.com/terms/views/view_a

with

            self.stdout.write(f'Project "{project.title}" [id={project.id}]:')
            if view_uris:
                self.stdout.write('- Tasks:')
                for task_uri in task_uris:
                    self.stdout.write(f'  - {task_uri}')
            if view_uris:
                self.stdout.write('- Views:')
                for view_uri in view_uris:
                    self.stdout.write(f'  - {view_uri}')
            self.stdout.write()

What do you think?

[MyPyDavid]

yes, with the uris may be better, Ive changed the show method and also adjusted the tests.
I think that the self.stdout.write is better for test-ability with the fixture capsys.readouterr().

[jochenklar]

Ah ok, but I think they are just the same. see https://docs.pytest.org/en/stable/how-to/capture-stdout-stderr.html#accessing-captured-output-from-a-test-function. No problem here though, just merge.