Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor searchRepositoryByName function and remove another redundant function #2371

Conversation

Morlinest
Copy link
Member

@Morlinest Morlinest commented Aug 23, 2017

Should fix some bugs (eg. #2365), should replace #2367 changes to models/repo_list.go.

I've rewrote function used by api/repo/search to give correct results. I commented everything, so hopefully it should be clear. Should include users repositories and also collaborative repositories (tested by user tests, finaly I see everything). Now returns repositories of related organizations based on public/private search (known/unknown Searcher or Searcher.IsAdmin) Also includes some protective logic.

My rewrite is based on assumption:

  1. Always searching for opts.OwnerID repositories
  2. opts.Searcher is here to identify who is searching and what rights this user has to search opts.OwnerID repositories.

Please check it.

PS: Integration tests would be usefull, but right now I can't do any tests for gitea.

@Morlinest
Copy link
Member Author

After tests I have to adjust it a little bit. There needs to be option to search without any owner.

@tboerger tboerger added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Aug 23, 2017
accessCond = accessCond.Or(builder.In("owner_id", ownerIds))

// Add repositories where user is set as collaborator directly
accessCond = accessCond.Or(builder.Expr(`id IN (SELECT repo_id FROM "access" WHERE access.user_id = ? AND owner_id != ?)`,
Copy link
Contributor

Choose a reason for hiding this comment

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

"access" is not valid SQL, it should be `access` instead

Copy link
Member Author

Choose a reason for hiding this comment

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

@CommanderRoot It is valid SQL, but each database can have different quotes string. Even in xorm is comment about it: mysql, sqlite use ` and postgres use ".

return nil, 0, err
}
if userExists == false {
return nil, 0, fmt.Errorf("User with OwnerID doesn't exist")
Copy link
Member

Choose a reason for hiding this comment

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

Please use ErrUserNotExist instead of fmt.Errorf(...)


// Return error if Owner ID is not set
if opts.OwnerID <= 0 {
return nil, 0, fmt.Errorf("OwnerID is not set")
Copy link
Member

Choose a reason for hiding this comment

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

Please use ErrUserNotExist instead of fmt.Errorf(...)

Copy link
Member

Choose a reason for hiding this comment

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

or in combination with ErrUserNotExist

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point, I'll use ErrUserNotExist{UID: opts.OwnerID}

@Morlinest Morlinest force-pushed the fix/missing-collaborative-repositories branch 2 times, most recently from 3052a2f to 9b0b204 Compare August 23, 2017 23:25
@Morlinest
Copy link
Member Author

Fix owner ID rules & rebased on master. Build still failing but it is not related to this PR.

if err != nil {
return nil, 0, err
}
if userExists == false {
Copy link
Member

Choose a reason for hiding this comment

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

Please prefer if !userExists { .. } to if userExists == false { .. }

Copy link
Member Author

Choose a reason for hiding this comment

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

Changed

isPublicSearch := true

// Allow to search for owners private data
if opts.Searcher != nil && (opts.Searcher.ID == searchOwnerID || opts.Searcher.IsAdmin) {
Copy link
Member

Choose a reason for hiding this comment

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

This may not be right; if the owner (i.e. searchOwnerID) is an organization, and the searcher is an owner of that organization, the searcher is allowed to view private repos, but with this implementation will not be able to.

More generally, I don't think we should be making authorization decisions in models; if the search should not return private repos, that is the responsibility of the caller (who should set opts.Private accordingly)

Copy link
Member Author

Choose a reason for hiding this comment

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

Removed

if opts.OwnerID <= 0 && opts.Searcher != nil {
searchOwnerID = opts.Searcher.ID
}
// Check if user with Owner ID exists
Copy link
Member

Choose a reason for hiding this comment

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

It's not clear to me why this check is necessary. If I search for the repos owned by a non-existent user, returning an empty list seems fine to me.

Copy link
Member Author

Choose a reason for hiding this comment

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

It's about opinion. Why would you do search if you know, there is no possible results? Also why not answer to searcher that he is using bad ID instead of telling him, this ID is OK but has no repositories.

@gsantner
Copy link

gsantner commented Aug 24, 2017

Is that too fixed with that PR? No repos show up in search, or are listed when nothing is searched

@lunny
Copy link
Member

lunny commented Aug 24, 2017

@gsantner I think #2367 has fixed the collabrative problems and has been merged to master.

@gsantner
Copy link

@lunny Oh, there was another push in between. Thanks! Yep, that fixed it

@lafriks
Copy link
Member

lafriks commented Aug 24, 2017

So is this needed anymore?

@Morlinest
Copy link
Member Author

@lafriks I think yes.

@Morlinest Morlinest force-pushed the fix/missing-collaborative-repositories branch from 8c12d6a to 09c32ab Compare August 24, 2017 20:28
@Morlinest
Copy link
Member Author

I am confused... Reading code again and again. There is no comments, no tests and I don't know what should be result of search in some cases.

  1. OwnerID > 0 && Searcher == nil
  2. OwnerID = 0 && Searcher == nil
  3. OwnerID > 0 && Searcher != nil
  4. OwnerID = 0 && Searcher != nil

@Morlinest Morlinest closed this Aug 25, 2017
@Morlinest
Copy link
Member Author

@lunny @lafriks Can someone explain, why there is need for SearchRepoOptions.OwnerID and SearchRepoOptions.Searcher please? I understand reason for OwnerID, but the second option is redudant. If function SearchRepositoryByName() should not check rights to repository (as @ethantkoenig mentioned), I don't see reason to have both variables there. It's very confusing. Now this function uses Searcher only if OwnerID is set. I think OwnerID and Collaborate option is everything we need here to construct "access" conditions.

@Morlinest Morlinest reopened this Aug 25, 2017
@Morlinest
Copy link
Member Author

No answers yet, but I couldn't stop working :D. I've changed code logic and think, it makes sense now. What are your opinions?

One thing I still don't like is starred option. It should be (if this will be merged) changed in #2326 to another type for filtering results.

@Morlinest Morlinest force-pushed the fix/missing-collaborative-repositories branch 3 times, most recently from 267192c to 15ddbc3 Compare August 26, 2017 00:45
@lunny lunny added this to the 1.x.x milestone Aug 27, 2017
@Morlinest
Copy link
Member Author

Any reaction, opinion?

@lafriks
Copy link
Member

lafriks commented Aug 30, 2017

@Morlinest had no time to look into this yet but one thing would be nice to have unit tests (as other PR) first to test all edge cases for this function to be able to verify that these changes does not break it

@Morlinest
Copy link
Member Author

@lafriks I was thinking about it too (now when I finally can run tests...). I'll add some new tests based on master and then change them for this PR (removing Searcher).

@lafriks
Copy link
Member

lafriks commented Aug 30, 2017

You could either create them as unit tests or integration tests (in such case changes would not be needed)

@Morlinest
Copy link
Member Author

@lafriks Added tests in #2453

@Morlinest Morlinest force-pushed the fix/missing-collaborative-repositories branch from c8ed267 to ab5d7cb Compare September 21, 2017 09:28
@daviian
Copy link
Member

daviian commented Sep 21, 2017

@Morlinest I am trying to review your PR 2371. It would make reviewing a lot easier if the integration tests were added before the refactoring happened. Would create more confidence that nothing has changed. Previous existing tests are simply not enough to conclude the same functionality.

@daviian
Copy link
Member

daviian commented Sep 21, 2017

@Morlinest I suggest to create a separate PR with the hugh amount of tests from here in order to speed up merging of your PR's. If they are all successful they can be merged quickly and than the other remaining PR's including this can be reviewed a lot faster.
@lafriks What do you say?

@Morlinest
Copy link
Member Author

Morlinest commented Sep 21, 2017

@daviian ... I did 3 separate PRs (you can read history of this thread). This (#2371) was first, but without tests (around +100 and -160 lines). Then I wanted to add tests and @lafriks also asked for them, so I've created second PR (#2453) with tests only (around 550 new lines of tests, later after merge simplified code by around 100-150 lines). But current implementation is bugged, so it could never pass all tests (read #2453 (comment)) and that is one of reason I started to rewriting it. To show everyone, that my new implementation works and all tests will pass, I've created third PR (#2468) that was merge of previous two.

After that all I was asking on discord #develop what can I do more (try to find "PRs (#2371 + #2453)", it starts on 7.9.2017). There I was asked to merge them (fix/feature with tests) into one so I did it (#2371 (comment); and closed separate PR with tests and with proof of concept). This PR is result of it...

I don't think it is hard to review. Real change is still around 100 new lines and 160 removed lines. A lot of lines are only comments and "one to one" changes (string for constant).

To help you with review, the only change (fix/rewrite/...) is in file models/repo_list.go and some related changes in files routers/api/v1/repo/repo.go and routers/user/profile.go. Every other file is related to tests.

@lunny
Copy link
Member

lunny commented Sep 22, 2017

@Morlinest I think we need some time to review your PRs. Don't worry! Of course, if some new PRs is easier to review, we have to review them at first.

@Morlinest Morlinest closed this Sep 22, 2017
@lunny lunny removed this from the 1.x.x milestone Sep 24, 2017
@go-gitea go-gitea locked and limited conversation to collaborators Nov 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants