Bump swh-auth requirement
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 13 2022
Sep 12 2022
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
Sep 9 2022
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 ObjectErrorCould 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.
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.
Sep 8 2022
Rebase
But clearly it's not great. I wonder if we could do something about this in swh-web instead
Sep 7 2022
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.