Skip to content

[74542] Implement PageInfo query#23092

Draft
shiroginne wants to merge 5 commits intodevfrom
implementation/74542-add-page-info-query-for-external-wiki-providers
Draft

[74542] Implement PageInfo query#23092
shiroginne wants to merge 5 commits intodevfrom
implementation/74542-add-page-info-query-for-external-wiki-providers

Conversation

@shiroginne
Copy link
Copy Markdown
Contributor

@shiroginne shiroginne commented May 6, 2026

Ticket

74542

What are you trying to accomplish?

Implement PageInfo query. DRY code a bit. Updated BaseQuery as well as UserQuery.
Rename UserQuery to User.

Merge checklist

  • Added/updated tests
  • Added/updated documentation in Lookbook (patterns, previews, etc)
  • Tested major browsers (Chrome, Firefox, Edge, ...)

DRY code a bit. Updated `BaseQuery` as well as `UserQuery`.
@shiroginne shiroginne self-assigned this May 6, 2026
@shiroginne shiroginne marked this pull request as ready for review May 6, 2026 15:23
@shiroginne shiroginne requested a review from a team May 6, 2026 15:24
@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 6, 2026

Caution

The provided work package version does not match the core version

Details:

Please make sure that:

  • The work package version OR your pull request target branch is correct

class PageInfoContract < DryApplicationContract
params do
required(:identifier).filled(:string)
optional(:access_token).maybe(:string)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I read the headline of the PR, I suspected that I would find exactly this in here 🙈

Is the current action plan to temporarily expect this optional parameter and work on a proper implementation of authorization strategies as the immediate next thing?

The pain that I have with reviewing this is that there will be a lot of code in the wrong place right now and we need to be aligned that this code is planned to be moved to the right place.

The alternative would be to leave this PR in draft state and tackle authentication first, then return here to finish the querying off properly.

CC @mereghost @Kharonus

OAuthClientToken.for_user_and_client(user, oauth_client).exists?
end

def user_access_token(user)
Copy link
Copy Markdown
Contributor

@NobodysNightmare NobodysNightmare May 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To give one example why I am skeptical of the approach of merging this PR first and then taking care of authentication: This is a method that's now added to the public interface of every provider.

In my mind, this method has to be removed in a subsequent PR and it's existence is only temporary. But I have no clue whether this is how you think about this method. You might want to keep it and then one of two things would happen at a later point:

  • I forget about this method and don't even mention it anymore; I will be very sad once I rediscover it
  • I don't forget about this method and ask in the 2nd PR why it's not gone; You will be very sad because you thought we were aligned on the path forward and I already approved this method in PR 1

@shiroginne shiroginne marked this pull request as draft May 7, 2026 09:33
@shiroginne
Copy link
Copy Markdown
Contributor Author

shiroginne commented May 7, 2026

I'm converting this PR to draft until the auth strategy is implemented 👨🏼‍💻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants