WIP: Always use backend response for requests to source/:project_name #16955
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
krauselukas
added
Frontend
krauselukas
commented
Oct 15, 2024
| end | ||
|
|
||
| def render_project_issues | ||
| set_issues_defaults | ||
| render partial: 'source/project_issues', formats: [:xml] | ||
| end | ||
|
|
||
| def render_project_packages | ||
| @packages = params.key?(:expand) ? @project.expand_all_packages : @project.packages.pluck(:name) |
There was a problem hiding this comment.
the expand parameter can be handled by the backend as well
krauselukas
changed the title
|
Set back to WIP since the minitests indicated some gaps... |
krauselukas
force-pushed
the
fix/issue_16911
branch
from
f8f5d12 to
43aca1c
Compare
krauselukas
commented
Oct 16, 2024
| # This implicitly also checks if the user can access the project (for hidden projects). | ||
| # We have to make sure to initialize the project already at this | ||
| # point, even we dont need the object in most cases because of that fact. | ||
| # TODO: Don't implicitly use the finder logic to authorize! |
There was a problem hiding this comment.
krauselukas
force-pushed
the
fix/issue_16911
branch
3 times, most recently
from
513e531 to
cab76c6
Compare
Right now we use the presence of the `?deleted=0` query parameter as a workaround to force the request being passed directly to the backend and returning results based on backend data over returning results based on frontend database entries. This workaround currently leads to inconsistant results being returned by the API. Instead of using this workaround we better should always let the backend handle the request (where possible) and return the data based on it's info. Fixes openSUSE#16911
In this case we want the return to avoid double render errors.
After changing the `source/:project_name` to always pass the request to the backend, the `count` attribute is not longer part of the `directory` tag. This was only included by the frontend.
Since we now always get the info from the backend on `source/:project_name` the multibuild flavors are included as well. We have to skip those when querying for `source/:project_name/:package_name/_meta` since multibuild flavors dont have their own meta file.
krauselukas
force-pushed
the
fix/issue_16911
branch
from
cab76c6 to
6a64e22
Compare
After creating package along the test, the frontend knows only about what exists in the fixtures (db) instead, but the backend still has the created package
danidoni
reviewed
Nov 8, 2024
| return | ||
| end | ||
|
|
||
| render_project_packages | ||
| raise InvalidParameterError, "'#{params[:view]}' is not a valid 'view' parameter value." unless params[:view].in?(%w[verboseproductlist productlist issues info]) |
There was a problem hiding this comment.
Where do we show this message?
danidoni
reviewed
Nov 8, 2024
danidoni
reviewed
Nov 8, 2024
Comment on lines
37
to
+39
| packages.elements('entry') do |p| | ||
| # skip multibuild flavors | ||
| next if p['name'].include?(':') |
There was a problem hiding this comment.
Try to use functional approaches when possible. It moves out the complexity from inside each iteration:
Suggested change
| packages.elements('entry') do |p| | |
| # skip multibuild flavors | |
| next if p['name'].include?(':') | |
| packages.elements('entry').reject {|p| p['name'].include?(':') }.each do |p| |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Right now we use the presence of the
?deleted=0query parameteras a workaround to force the request being passed directly to the
backend and returning results based on backend data over returning
results based on frontend database entries.
This workaround currently leads to inconsistant results being returned
by the API.
Instead of using this workaround we better should always
let the backend handle the request (where possible) and return
the data based on it's info.
Fixes #16911
Replaces #16928
So in short, after introducing this change we always deliver what
?delete=0was doing before.