Bump swh-auth requirement

However, that parameter can be omitted in that case so we can safely rename it and I will update that doc.

Use next as redirect field name (default in django.contrib.auth).

In D8420#219458, @anlambert wrote:

In D8420#219455, @olasd wrote:

Is there anything preventing swh-auth from using next= instead of next_path=?

I do not think we shared such URLs in the wild as they are used internally during login process
so we could rename the query parameter to next in swh-auth yes, that would be simpler for sure.

In D8420#219455, @olasd wrote:

Is there anything preventing swh-auth from using next= instead of next_path=?

Hmm, that's not a setting, your change is overriding a module-level variable (which may be fine? but may not be? Really depends on import ordering and whether code in settings.py is run before other modules import django.contrib.auth).

In D8420#219364, @anlambert wrote:

In D8420#219363, @olasd wrote:

While you're refactoring this, is there a reason for not using the default REDIRECT_FIELD_NAME from django.contrib.auth ("next") for the login/logout views, instead of "next_path"? This would save us from having to override it on every user_passes_test call.

Oh I missed that django setting, let me check.

Prefer to override django.contrib.auth.REDIRECT_FIELD_NAME instead of
using redirect_field_name parameter in auth related decorators.

In D8420#219363, @olasd wrote:

While you're refactoring this, is there a reason for not using the default REDIRECT_FIELD_NAME from django.contrib.auth ("next") for the login/logout views, instead of "next_path"? This would save us from having to override it on every user_passes_test call.

Bump swh.core requirement

Looks good to me.

Update:

• rename some fixtures
• remove unneeded monkeypatch fixture use

In D8430#219136, @swh-public-ci wrote:

Build has FAILED

Patch application report for D8430 (id=30422)

Rebasing onto 6cdf6d3004...

Current branch diff-target is up to date.

Changes applied before test

commit 010b59e10b541a1d6fe039c0cfb98da0c8eb3410
Author: Antoine Lambert <anlambert@softwareheritage.org>
Date:   Thu Sep 8 17:21:01 2022 +0200

    loader: Add origin URL and visit type as sentry tags
    
    It enables to search sentry events related to a particular loaded origin
    URL or for a given visit type from the sentry Web UI.

Link to build: https://jenkins.softwareheritage.org/job/DLDBASE/job/tests-on-diff/865/
See console output for more information: https://jenkins.softwareheritage.org/job/DLDBASE/job/tests-on-diff/865/console

Remove package loader from changeset

Update:

• Move sentry_sdk.set_tag calls in BaseLoader constructor in order for package loaders to also benefit from them in sentry reports
• Add test for package loader checking tags are correctly sent to sentry

Rebase

Add info about other listers planned to be implemented or currently implemented:

Rebase

Snapshot is available only in a visit status with 'full' status.

In D8426#219077, @anlambert wrote:

In D8426#219076, @jayeshv wrote:

> I do not get the issue here, using the following changes on top of your diff, it works as expected:
>

It will work as expected in the data part. But there will be an error associated, that we think is unnecessary.
With your changes, it will be a "NoneType' object has no attribute 'object_id" instead of an ObjectError

Could you write a snippet query to reproduce the error ? I still do not get what's wrong here.

In D8426#219076, @jayeshv wrote:

> I do not get the issue here, using the following changes on top of your diff, it works as expected:
>

It will work as expected in the data part. But there will be an error associated, that we think is unnecessary.
With your changes, it will be a "NoneType' object has no attribute 'object_id" instead of an ObjectError

In D8426#219051, @jayeshv wrote:

In D8426#219043, @vlorentz wrote:

Why have two different types, instead of making the snapshot field nullable, like this?

type VisitStatus {
  status: String!
  date: DateTime!
  type: String
  snapshot: Snapshot
}

That is the existing system.
The issue is snapshot has non nullable fields (like SWHID) and GraphQL standard will not allow a
null for an object with non nullable field without an error.

I think it will be a bad idea to remove non-nullable fields from the Sanpshot object.

Looks good to me.

In D8430#218927, @vlorentz wrote:

Hmm, I was about to say:

I think it would make more sense to use breadcrumbs here.

I used tags in swh-indexer because it handles origins and objects in batch, so "current origin/object" keeps changing back and forth.

But actually, breadcrumbs are flooded with request logs, so I guess tags are good to make this visible.

Rebase

But clearly it's not great. I wonder if we could do something about this in swh-web instead

In D8407#218601, @ardumont wrote:

Thanks.

fwiw, i think this should be added with diffs by the contributors of those new listers/loaders.

@bchauvet ^ I expected this to be done already.

@franckbret for your information, i must have forgotten to be explicit about this before so ;)

@franckbret fyi you have updated the wrong diff (pubdev instead of haskell)

Rebase

Rebase

Raising priority as it's been four months since the lister is stuck in production.