An error occurred fetching the project authors.
  1. 15 Dec, 2020 1 commit
  2. 20 Jul, 2020 1 commit
    • Patrick Bajao's avatar
      Make inapplicable_reason text to be reusable · 8e532be8
      Patrick Bajao authored
      We also need to display the inapplicable_reason text in another
      place (`Gitlab::Suggestions::SuggestionSet`).
      
      There's no need to return `inapplicable_reason` as symbol for now
      so it was converted to return text instead.
      8e532be8
  3. 03 Jul, 2020 1 commit
    • Patrick Bajao's avatar
      Include inapplicable_reason in API response · 1f4d254e
      Patrick Bajao authored
      In order for frontend to display appropriate messages on why
      a suggestion can't be applied, it needs to know the reason.
      
      A new `inapplicable_reason` property is introduced and included in
      the API response to achieve that. It is based on the checks to
      determine whether a suggestion can be applied.
      
      The following reasons are:
      
      - "You don't have write access to the source branch." - when user
        has no write access to branch.
      - "This merge request was merged. To apply this suggestion, edit
        this file directly." - when MR was merged.
      - "This merge request is closed. To apply this suggestion, edit
        this file directly." - when MR is closed.
      - "Can't apply as the source branch was deleted." - when source
        branch is deleted.
      - "Can't apply as this line was changed in a more recent version."
        - when the line where suggestion is on is outdated.
      - "Can't apply as these lines were changed in a more recent
        version." - when lines where suggestion is on are outdated.
      - "This suggestion already matches its content." - when suggestion
        has the same content as the line it is on.
      - "Can't apply this suggestion." - default message when suggestion
        cannot be applied but doesn't fall into any of criteria above.
        We won't show this message anywhere right now but it makes sense
        to return something (e.g. when suggestion is already applied).
      1f4d254e
  4. 23 Jun, 2020 1 commit
  5. 23 Sep, 2019 1 commit
    • Oswaldo Ferreira's avatar
      Adjust unnapliable suggestions in expanded lines · 7998e114
      Oswaldo Ferreira authored
      When expanding diff lines and leaving suggestion comments,
      eventually, they showed as unnapliable
      even with no changes in the diff.
      
      It happened given the `DiffNote#supports_suggestion?` check was
      being made at `Suggestion#appliable?` in the discussions iteration.
      
      The problem with `DiffNote#supports_suggestion?` as it is that
      it uses `Position#diff_file`, which has a RequestStore "cache".
      
      So for instance, if we have 3 comments in expanded diff lines
      for the same diff file, just the _first_ expansion would be
      considered, therefore, just the _first_ suggestion within
      this set of comments on expanded lines would be
      appliable.
      
      All in all, we're able to simply remove this check from the
      `appliable?` method given we already check if the note supports
      suggestions uppon creation (`Suggestions::CreateService`).
      
      As an extra outcome, we'll submit less Gitaly requests.
      7998e114
  6. 04 Apr, 2019 1 commit
  7. 13 Dec, 2018 2 commits