Adding Type annotations #1290
Adding Type annotations #1290
Conversation
Summary by CodeRabbit
Summary by CodeRabbit
WalkthroughThis change introduces extensive type annotations across the backend codebase, updating function and method signatures, properties, and variables to specify parameter and return types. It also adds a Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Suggested reviewers
Tip ⚡💬 Agentic Chat (Pro Plan, General Availability)
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🔭 Outside diff range comments (4)
backend/apps/github/models/mixins/repository.py (1)
126-129: 🛠️ Refactor suggestionMissing type annotation for
idx_topicsproperty.While all other property methods in this class now have type annotations,
idx_topicsis missing one. Based on the method name and similar properties, it likely should return a list of strings.@property -def idx_topics(self): +def idx_topics(self) -> list[str]: """Return topics for indexing.""" return self.topicsbackend/apps/common/geocoding.py (1)
11-23: 💡 Verification agent🧩 Analysis chain
Return type annotation inconsistent with docstring.
The function's return type is annotated as
Location, but the docstring (line 19) states it returnsLocation|None. This inconsistency should be addressed.-def get_location_coordinates(query, delay: int = 2) -> Location: +def get_location_coordinates(query, delay: int = 2) -> Location | None:Let's verify whether the function can actually return
None:
🏁 Script executed:
#!/bin/bash # Check if the function can return None grep -A 2 "return Nominatim" backend/apps/common/geocoding.pyLength of output: 144
Action Required: Update Function's Return Type Annotation
The verification confirms that the
geocode(query)method can indeed returnNonewhen a location is not found. Therefore, the return type of the function should be updated to reflect that possibility. Please update the annotation as follows:-def get_location_coordinates(query, delay: int = 2) -> Location: +def get_location_coordinates(query, delay: int = 2) -> Location | None:This change will align the type annotation with the docstring which specifies that the function returns
Location | None.backend/apps/github/models/repository_contributor.py (1)
76-104: 🛠️ Refactor suggestionMissing return type annotation for update_data method.
The method has been updated to make
savea keyword-only parameter with type annotation, but it's missing a return type annotation. According to the docstring (line 86), this method returns aRepositoryContributorinstance.- def update_data(gh_contributor, repository, user, *, save: bool = True): + def update_data(gh_contributor, repository, user, *, save: bool = True) -> "RepositoryContributor":This would be consistent with similar
update_datamethods in other model classes, such as inOrganizationandPullRequest.backend/apps/owasp/models/chapter.py (1)
183-205:⚠️ Potential issueGood use of keyword-only parameter and forward reference.
The
*,notation for makingsavea keyword-only parameter is a good practice. The use of a string literal-> "Project"as a forward reference for the return type is correct when returning an instance of the class in which the method is defined.However, the return type appears to be incorrect. The method returns a
Chapterinstance, not aProjectinstance.-def update_data(gh_repository, repository, *, save: bool = True) -> "Project": +def update_data(gh_repository, repository, *, save: bool = True) -> "Chapter":
🧹 Nitpick comments (49)
backend/apps/github/admin.py (2)
78-78: Consider adding type annotations to the IssueAdmin.custom_field_github_url method.For consistency, this method should also have type annotations similar to the one in PullRequestAdmin.
- def custom_field_github_url(self, obj): + def custom_field_github_url(self, obj: Issue) -> str:
121-121: Consider adding type annotations to the RepositoryAdmin.custom_field_github_url method.For consistency, this method should also have type annotations similar to the other methods.
- def custom_field_github_url(self, obj): + def custom_field_github_url(self, obj: Repository) -> str:backend/apps/owasp/management/commands/add_project_custom_tags.py (1)
15-15: Consider adding parameter type annotation.For completeness, consider adding a type annotation for the
parserparameter.- def add_arguments(self, parser) -> None: + def add_arguments(self, parser: argparse.ArgumentParser) -> None:You'll need to add the corresponding import:
from argparse import ArgumentParserbackend/apps/github/common.py (1)
22-24: Consider adding parameter type annotations.For completeness, consider adding type annotations for the function parameters, especially since their types are documented in the docstring.
def sync_repository( - gh_repository, organization=None, user=None + gh_repository: github.Repository.Repository, + organization: Organization = None, + user: User = None ) -> tuple[Organization, Repository]:You'll need to add the corresponding import:
import githubor more specificallyfrom github import Repository as GithubRepositorybackend/apps/owasp/models/sponsor.py (1)
74-74: Type annotations for bulk_save could be more specificWhile the current type annotations are correct, they could be more specific to improve type checking:
-def bulk_save(sponsors: list, fields: list = None) -> None: +def bulk_save(sponsors: list["Sponsor"], fields: list[str] | None = None) -> None:This change would:
- Specify that the
sponsorslist containsSponsorobjects- Specify that the
fieldslist contains strings- Use
Noneas the default value for consistency with Python's stylebackend/apps/core/validators.py (2)
54-54: Add missing type annotations to validate_page function.While the other validator functions have been updated with type annotations, this function is missing the same treatment.
-def validate_page(page): +def validate_page(page: int) -> None:
98-98: Consider using a more specific list type annotation.While the current annotation is correct, a more specific type like
list[str]orlist[dict]would provide better type information, depending on what facet_filters actually contains.backend/apps/owasp/models/mixins/chapter.py (1)
59-76: Consider adding type annotations to remaining properties.For consistency, the remaining property methods (
idx_related_urls,idx_suggested_location,idx_top_contributors, andidx_updated_at) should also have return type annotations added.@property -def idx_related_urls(self): +def idx_related_urls(self) -> list: """Return related URLs for indexing.""" return self.related_urls @property -def idx_suggested_location(self): +def idx_suggested_location(self) -> str: """Return suggested location for indexing.""" return self.suggested_location if self.suggested_location != "None" else "" @property -def idx_top_contributors(self): +def idx_top_contributors(self) -> list: """Return top contributors for indexing.""" return super().get_top_contributors(repositories=[self.owasp_repository]) @property -def idx_updated_at(self): +def idx_updated_at(self) -> float: """Return updated at for indexing.""" return (self.updated_at or self.owasp_repository.updated_at).timestamp()backend/apps/core/models/prompt.py (2)
42-42: Add type annotation to get_text method.For consistency with other static methods, the
get_textmethod should have a return type annotation. Note that this method can returnNoneif the prompt doesn't exist.@staticmethod -def get_text(key): +def get_text(key: str) -> str | None: """Return prompt by key. Args: key (str): The key of the prompt. Returns: str: The text of the prompt, or None if not found. """
59-59: Consider more precise return type annotations.All these methods return the result of
get_text(), which can potentially returnNoneif the prompt doesn't exist. Consider usingstr | Noneor importingOptionalfromtypingand usingOptional[str]for a more precise type annotation.Also applies to: 69-69, 79-79, 89-89, 99-99, 109-109, 119-119, 129-129, 139-139
backend/apps/owasp/models/mixins/project.py (4)
42-44: Add missing type annotation to idx_issues_count.For consistency with other property methods, this method should have a return type annotation.
@property -def idx_issues_count(self): +def idx_issues_count(self) -> int: """Return issues count for indexing.""" return self.open_issues.count()
52-52: Consider using a more specific list type annotation.While
listis correct, a more specific type likelist[str]would provide better type information, making it clear thatidx_languagesreturns a list of strings.
77-77: Consider using a more specific list type annotation.While
listis correct, a more specific type likelist[dict]or evenlist[dict[str, Union[int, str]]]would provide better type information.
105-107: Add missing type annotation to idx_top_contributors.For consistency with other property methods, this method should have a return type annotation.
@property -def idx_top_contributors(self): +def idx_top_contributors(self) -> list: """Return top contributors for indexing.""" return super().get_top_contributors(repositories=self.repositories.all())backend/apps/github/models/mixins/repository.py (1)
16-23: Consider adding type annotation tois_indexableproperty.For consistency with other properties in this class, consider adding a type annotation (likely
-> bool) to theis_indexableproperty.@property -def is_indexable(self): +def is_indexable(self) -> bool: """Repositories to index.""" return ( not self.is_archived and not self.is_empty and not self.is_template and self.project_set.exists() )backend/apps/owasp/index/project.py (2)
98-101: Consider adding return type annotation toupdate_synonymsstatic method.For consistency with the
configure_replicasmethod, consider adding a return type annotation to theupdate_synonymsstatic method.@staticmethod -def update_synonyms(): +def update_synonyms() -> dict: """Update synonyms.""" return IndexBase.reindex_synonyms("owasp", "projects")Run this verification script to determine the correct return type:
#!/bin/bash # Check the return type of IndexBase.reindex_synonyms grep -A 5 "def reindex_synonyms" backend/apps/common/index.py
102-107: Consider adding return type annotation toget_entitiesmethod.For consistency with other methods, consider adding a return type annotation to the
get_entitiesmethod to specify the return type of the QuerySet.-def get_entities(self): +def get_entities(self) -> 'QuerySet[Project]': """Get entities for indexing.""" return Project.objects.prefetch_related( "organizations", "repositories", )backend/apps/owasp/graphql/nodes/chapter.py (1)
37-37: Type annotation correctly applied toresolve_geo_locationmethod.The return type annotation
-> GeoLocationTypeaccurately specifies the return type of this resolver method, enhancing type safety and code clarity.Consider adding similar return type annotations to the other resolver methods (
resolve_keyandresolve_suggested_location) for consistency across the codebase:- def resolve_key(self, info): + def resolve_key(self, info) -> str: """Resolve key.""" return self.idx_key - def resolve_suggested_location(self, info): + def resolve_suggested_location(self, info) -> str: """Resolve suggested location.""" return self.idx_suggested_locationbackend/apps/slack/commands/donate.py (1)
13-13: Return type annotation is good, but parameter type annotation is missingThe addition of the
-> Nonereturn type annotation is appropriate for this function.However, it seems the
clientparameter is not annotated with its type (WebClientfrom slack_sdk), even though the docstring indicates it is of typeslack_sdk.WebClient. Consider adding the parameter type annotation for consistency with other similar handler functions in the codebase.-def donate_handler(ack, command, client) -> None: +from slack_sdk.web import WebClient + +def donate_handler(ack, command, client: WebClient) -> None:backend/apps/github/api/search/user.py (1)
8-10: Type annotations could be more completeThe type annotations for
query,limit,page, and the return type are correctly implemented. However, the parametersattributesandsearchable_attributeslack type annotations, even though they're described in the docstring as lists.Consider enhancing the type annotations for all parameters:
def get_users( - query: str, attributes=None, limit: int = 25, page: int = 1, searchable_attributes=None + query: str, attributes: list[str] = None, limit: int = 25, page: int = 1, searchable_attributes: list[str] = None ) -> dict:Or if you prefer to use the more flexible
Optionaltype:from typing import Optional, List def get_users( - query: str, attributes=None, limit: int = 25, page: int = 1, searchable_attributes=None + query: str, attributes: Optional[List[str]] = None, limit: int = 25, page: int = 1, searchable_attributes: Optional[List[str]] = None ) -> dict:backend/apps/github/graphql/queries/repository_contributor.py (1)
20-20: Consider using more specific type annotations for the return value.The type annotation for
limitis correctly specified asint. However, the return type annotation could be more specific than justlist. If you're using Python 3.9+, consider usinglist[RepositoryContributorNode]for better type specificity.- def resolve_top_contributors(root, info, limit: int) -> list: + def resolve_top_contributors(root, info, limit: int) -> list[RepositoryContributorNode]:backend/apps/owasp/api/search/committee.py (1)
8-8: Type annotations are clear, but could be more specific.The type annotations match the docstring descriptions well. Consider these improvements:
- Since
attributescan beNone, it should useOptional[list]orlist | None(Python 3.10+)- If using Python 3.9+, consider more specific collection types like
list[str]for attributes-def get_committees(query: str, attributes: list = None, limit: int = 25, page: int = 1) -> dict: +from typing import Optional +def get_committees(query: str, attributes: Optional[list[str]] = None, limit: int = 25, page: int = 1) -> dict:backend/apps/slack/commands/leaders.py (1)
15-15: Missing type annotation for 'ack' parameterWhile you've added type annotations for
commandandclient, theackparameter is still missing a type annotation.-def leaders_handler(ack, command: dict, client: WebClient) -> None: +from typing import Callable + +def leaders_handler(ack: Callable, command: dict, client: WebClient) -> None:backend/apps/slack/events/app_home_opened.py (1)
16-16: Consider adding type annotation for the ack parameterWhile the type annotations for
eventandclientare correct, theackparameter could benefit from having a type annotation as well. According to the docstring, it's a function, so it could be annotated with a callable type.-def app_home_opened_handler(event: dict, client: WebClient, ack) -> None: +def app_home_opened_handler(event: dict, client: WebClient, ack: Callable[[], Any]) -> None:This would require adding
from typing import Any, Callableto the imports.backend/apps/slack/commands/policies.py (1)
14-14: Function signature type annotations look good, consider adding type for ackThe type annotations for
commandandclientmatch the docstring descriptions, and the return type annotation is appropriate. Consider adding a type annotation for theackparameter as well for consistency.-def policies_handler(ack, command: dict, client: WebClient) -> None: +def policies_handler(ack: Callable[[], Any], command: dict, client: WebClient) -> None:This would require adding
from typing import Any, Callableto the imports.backend/apps/slack/commands/news.py (1)
14-14: Function signature type annotations look good, consider adding type for ackThe type annotations for
commandandclientmatch the docstring descriptions, and the return type annotation is appropriate. Consider adding a type annotation for theackparameter as well for consistency.-def news_handler(ack, command: dict, client: WebClient) -> None: +def news_handler(ack: Callable[[], Any], command: dict, client: WebClient) -> None:This would require adding
from typing import Any, Callableto the imports.backend/apps/slack/commands/sponsors.py (1)
15-15: Type annotation doesn't match docstring description.The function signature correctly uses
WebClientas the type annotation for theclientparameter, but the docstring describes it asSlackClient. This inconsistency should be resolved by updating the docstring to match the type annotation.ack (function): Function to acknowledge the Slack command. command (dict): The Slack command payload. - client (SlackClient): The Slack client instance for sending messages. + client (slack_sdk.WebClient): The Slack client instance for sending messages.Also applies to: 21-21
backend/apps/slack/common/handlers/committees.py (1)
18-22: LGTM! Clear and appropriate type annotations.The parameter type annotations accurately reflect the expected types, and the return type annotation correctly indicates that the function returns a list. These annotations improve type safety and code clarity.
While the
-> listreturn type is correct, you could consider using a more specific type annotation like-> list[dict]in the future to indicate the structure of the list elements, assuming they are dictionaries representing Slack blocks.backend/apps/slack/commands/chapters.py (1)
20-23: Minor docstring inconsistencyThe docstring still refers to
clientasslack_sdk.WebClientwhile the type annotation usesWebClient. While this doesn't affect functionality, consider updating the docstring for complete consistency.Args: ack (function): Acknowledge the Slack command request. command (dict): The Slack command payload. - client (slack_sdk.WebClient): The Slack WebClient instance for API calls. + client (WebClient): The Slack WebClient instance for API calls.backend/apps/slack/commands/events.py (1)
18-21: Docstring inconsistency with type annotationThe docstring still refers to the
clientparameter asSlackClientwhile the type annotation usesWebClient. This inconsistency could cause confusion for developers.Args: ack (function): Function to acknowledge the Slack command. command (dict): The Slack command payload. - client (SlackClient): The Slack client instance for sending messages. + client (WebClient): The Slack client instance for sending messages.backend/apps/github/graphql/queries/issue.py (1)
21-23: Good addition of type hints, but consider adding one forloginparameter.The type hints for
limitanddistinctparameters and the return type annotation are well-implemented. For consistency, consider adding a type annotation for theloginparameter as well, which should bestr | Nonebased on its usage.def resolve_recent_issues( - root, info, limit: int, *, distinct: bool = False, login=None + root, info, limit: int, *, distinct: bool = False, login: str | None = None ) -> QuerySet:backend/apps/slack/common/handlers/chapters.py (1)
17-22: Good type annotations added, but return type could be more specific.The type annotations for parameters are well-implemented and align perfectly with the function's usage. For the return type, while
listis correct, it could be more specific about what kind of list is being returned (a list of Slack blocks).def get_blocks( page: int = 1, search_query: str = "", limit: int = 10, presentation: EntityPresentation | None = None, -) -> list: +) -> list[dict]:backend/apps/github/graphql/queries/pull_request.py (1)
21-23: Good addition of type hints, but consider adding one forloginparameter.The type hints for
limitanddistinctparameters and the return type annotation are well-implemented. For consistency, consider adding a type annotation for theloginparameter as well, which should bestr | Nonebased on its usage.def resolve_recent_pull_requests( - root, info, limit: int, *, distinct: bool = False, login=None + root, info, limit: int, *, distinct: bool = False, login: str | None = None ) -> QuerySet:backend/apps/owasp/api/search/project.py (1)
10-16: Type annotations added to get_projects function parameters and return typeGood addition of type annotations to specify parameter types and the return type of the function. This improves code readability and enables better static type checking.
However, the
listtype annotation could be more specific to indicate what the lists contain.Consider using more specific type annotations for the list parameters:
- attributes: list = None, + attributes: list[str] = None, - searchable_attributes: list = None, + searchable_attributes: list[str] = None,backend/apps/owasp/management/commands/owasp_process_snapshots.py (1)
55-55: Consider adding parameter type annotation.While the return type annotation is correct, the
snapshotparameter could benefit from a type annotation specifying it's aSnapshotobject.-def process_snapshot(self, snapshot) -> None: +def process_snapshot(self, snapshot: Snapshot) -> None:backend/apps/slack/blocks.py (2)
34-34: Consider more specific return type annotation.While
-> listis correct, a more specific type like-> list[dict]or-> list[dict[str, Any]]would provide better type information.-def get_header() -> list: +def get_header() -> list[dict[str, Any]]:
90-90: Add parameter type annotations.While the return type annotation is thorough, consider adding type annotations for the parameters as well.
-def get_pagination_buttons(entity_type, page, total_pages) -> list[dict[str, Any]]: +def get_pagination_buttons(entity_type: str, page: int, total_pages: int) -> list[dict[str, Any]]:backend/apps/common/open_ai.py (3)
48-48: Add parameter type annotation for max_tokens.While the return type annotation is good, the
max_tokensparameter should have a type annotation, especially since it's documented as an int in the docstring.-def set_max_tokens(self, max_tokens) -> "OpenAi": +def set_max_tokens(self, max_tokens: int) -> "OpenAi":
62-62: Add parameter type annotation for content.While the return type annotation is good, the
contentparameter should have a type annotation, especially since it's documented as a str in the docstring.-def set_prompt(self, content) -> "OpenAi": +def set_prompt(self, content: str) -> "OpenAi":
76-76: Missing return type annotation for complete method.While you've added return type annotations to other methods, the
completemethod is missing one. Consider adding-> str | Noneto indicate it returns either a string or None.-def complete(self): +def complete(self) -> str | None:backend/apps/core/utils/index.py (2)
124-135: Consider using a more flexible type annotation for app_names parameter.While the type annotation
tuple[str, str]matches the default value("github", "owasp"), it's overly restrictive as it only allows exactly two strings.-def register_indexes(app_names: tuple[str, str] = ("github", "owasp")) -> None: +def register_indexes(app_names: tuple[str, ...] = ("github", "owasp")) -> None:This would allow the function to accept a tuple of any number of strings, making it more flexible for future expansion.
137-148: Consider using a more flexible type annotation for app_names parameter.Similar to the
register_indexesfunction, the type annotationtuple[str, str]is overly restrictive.-def unregister_indexes(app_names: tuple[str, str] = ("github", "owasp")) -> None: +def unregister_indexes(app_names: tuple[str, ...] = ("github", "owasp")) -> None:This would allow the function to accept a tuple of any number of strings, making it more flexible for future expansion.
backend/apps/owasp/models/project.py (1)
246-254: Missing parameter type annotations.The
bulk_savemethod has a-> Nonereturn type but lacks type annotations for its parameters. Consider adding type annotations to the parameters for consistency with other methods.-def bulk_save(projects, fields=None) -> None: +def bulk_save(projects: list, fields: list | None = None) -> None:backend/apps/common/management/commands/generate_sitemap.py (6)
160-182: Consider adding type annotations togenerate_sitemap_contentmethodWhile you've added type annotations to all other methods, the
generate_sitemap_contentmethod is missing type annotations. For consistency, consider adding parameter and return type annotations to this method as well.- def generate_sitemap_content(self, routes): + def generate_sitemap_content(self, routes: list) -> str:
184-184: Consider using more specific type annotationWhile
listis correct, usingList[str]would provide more specific type information about the elements in the list. This requires importingListfrom thetypingmodule.+from typing import Dict, List - def generate_index_sitemap(self, sitemap_files: list) -> str: + def generate_index_sitemap(self, sitemap_files: List[str]) -> str:
203-203: Consider using more specific type annotationFor
url_data, usingDict[str, str]orDict[str, Any]would provide more specific type information. This requires importingDictand possiblyAnyfrom thetypingmodule.+from typing import Any, Dict - def create_url_entry(self, url_data: dict) -> str: + def create_url_entry(self, url_data: Dict[str, Any]) -> str:
222-222: Consider using more specific type annotationFor
sitemap_data, usingDict[str, str]would provide more specific type information about the keys and values in the dictionary.- def create_sitemap_index_entry(self, sitemap_data: dict) -> str: + def create_sitemap_index_entry(self, sitemap_data: Dict[str, str]) -> str:
236-236: Consider using more specific type annotationFor
urls, usingList[str]would provide more specific type information about the elements in the list.- def create_sitemap(self, urls: list) -> str: + def create_sitemap(self, urls: List[str]) -> str:
253-253: Consider using more specific type annotationFor
sitemaps, usingList[str]would provide more specific type information about the elements in the list.- def create_sitemap_index(self, sitemaps: list) -> str: + def create_sitemap_index(self, sitemaps: List[str]) -> str:
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
backend/poetry.lockis excluded by!**/*.lock
📒 Files selected for processing (107)
.pre-commit-config.yaml(1 hunks)backend/apps/common/geocoding.py(1 hunks)backend/apps/common/index.py(10 hunks)backend/apps/common/management/commands/algolia_update_replicas.py(1 hunks)backend/apps/common/management/commands/algolia_update_synonyms.py(1 hunks)backend/apps/common/management/commands/generate_sitemap.py(12 hunks)backend/apps/common/management/commands/load_data.py(1 hunks)backend/apps/common/management/commands/purge_data.py(1 hunks)backend/apps/common/models.py(1 hunks)backend/apps/common/open_ai.py(4 hunks)backend/apps/common/utils.py(8 hunks)backend/apps/core/api/algolia.py(3 hunks)backend/apps/core/models/prompt.py(11 hunks)backend/apps/core/utils/index.py(3 hunks)backend/apps/core/validators.py(5 hunks)backend/apps/github/admin.py(2 hunks)backend/apps/github/api/search/user.py(1 hunks)backend/apps/github/common.py(1 hunks)backend/apps/github/graphql/queries/issue.py(2 hunks)backend/apps/github/graphql/queries/pull_request.py(2 hunks)backend/apps/github/graphql/queries/release.py(2 hunks)backend/apps/github/graphql/queries/repository_contributor.py(1 hunks)backend/apps/github/index/release.py(2 hunks)backend/apps/github/index/repository.py(2 hunks)backend/apps/github/index/user.py(2 hunks)backend/apps/github/management/commands/github_enrich_issues.py(2 hunks)backend/apps/github/management/commands/github_update_owasp_organization.py(2 hunks)backend/apps/github/management/commands/github_update_project_related_repositories.py(2 hunks)backend/apps/github/models/common.py(1 hunks)backend/apps/github/models/generic_issue_model.py(1 hunks)backend/apps/github/models/issue.py(7 hunks)backend/apps/github/models/label.py(2 hunks)backend/apps/github/models/mixins/release.py(2 hunks)backend/apps/github/models/mixins/repository.py(2 hunks)backend/apps/github/models/organization.py(3 hunks)backend/apps/github/models/pull_request.py(2 hunks)backend/apps/github/models/release.py(3 hunks)backend/apps/github/models/repository.py(5 hunks)backend/apps/github/models/repository_contributor.py(3 hunks)backend/apps/github/models/user.py(3 hunks)backend/apps/github/utils.py(5 hunks)backend/apps/owasp/admin.py(1 hunks)backend/apps/owasp/api/search/chapter.py(1 hunks)backend/apps/owasp/api/search/committee.py(1 hunks)backend/apps/owasp/api/search/issue.py(1 hunks)backend/apps/owasp/api/search/project.py(1 hunks)backend/apps/owasp/graphql/nodes/chapter.py(1 hunks)backend/apps/owasp/graphql/nodes/committee.py(1 hunks)backend/apps/owasp/graphql/nodes/common.py(1 hunks)backend/apps/owasp/graphql/queries/post.py(1 hunks)backend/apps/owasp/graphql/queries/stats.py(1 hunks)backend/apps/owasp/index/project.py(1 hunks)backend/apps/owasp/management/commands/add_project_custom_tags.py(2 hunks)backend/apps/owasp/management/commands/owasp_aggregate_projects.py(2 hunks)backend/apps/owasp/management/commands/owasp_enrich_chapters.py(2 hunks)backend/apps/owasp/management/commands/owasp_enrich_committees.py(2 hunks)backend/apps/owasp/management/commands/owasp_enrich_events.py(2 hunks)backend/apps/owasp/management/commands/owasp_enrich_projects.py(2 hunks)backend/apps/owasp/management/commands/owasp_process_snapshots.py(3 hunks)backend/apps/owasp/management/commands/owasp_scrape_chapters.py(2 hunks)backend/apps/owasp/management/commands/owasp_scrape_committees.py(2 hunks)backend/apps/owasp/management/commands/owasp_scrape_projects.py(2 hunks)backend/apps/owasp/management/commands/owasp_sync_posts.py(3 hunks)backend/apps/owasp/management/commands/owasp_update_events.py(1 hunks)backend/apps/owasp/management/commands/owasp_update_project_health_requirements.py(2 hunks)backend/apps/owasp/management/commands/owasp_update_sponsors.py(1 hunks)backend/apps/owasp/models/chapter.py(9 hunks)backend/apps/owasp/models/committee.py(3 hunks)backend/apps/owasp/models/event.py(10 hunks)backend/apps/owasp/models/mixins/chapter.py(2 hunks)backend/apps/owasp/models/mixins/project.py(5 hunks)backend/apps/owasp/models/post.py(3 hunks)backend/apps/owasp/models/project.py(6 hunks)backend/apps/owasp/models/project_health_metrics.py(1 hunks)backend/apps/owasp/models/project_health_requirements.py(1 hunks)backend/apps/owasp/models/snapshot.py(1 hunks)backend/apps/owasp/models/sponsor.py(3 hunks)backend/apps/owasp/scraper.py(3 hunks)backend/apps/slack/actions/home.py(2 hunks)backend/apps/slack/apps.py(3 hunks)backend/apps/slack/blocks.py(4 hunks)backend/apps/slack/commands/board.py(2 hunks)backend/apps/slack/commands/chapters.py(2 hunks)backend/apps/slack/commands/committees.py(2 hunks)backend/apps/slack/commands/community.py(2 hunks)backend/apps/slack/commands/contact.py(2 hunks)backend/apps/slack/commands/contribute.py(2 hunks)backend/apps/slack/commands/donate.py(1 hunks)backend/apps/slack/commands/events.py(2 hunks)backend/apps/slack/commands/gsoc.py(2 hunks)backend/apps/slack/commands/jobs.py(2 hunks)backend/apps/slack/commands/leaders.py(2 hunks)backend/apps/slack/commands/news.py(2 hunks)backend/apps/slack/commands/owasp.py(2 hunks)backend/apps/slack/commands/policies.py(2 hunks)backend/apps/slack/commands/projects.py(2 hunks)backend/apps/slack/commands/sponsor.py(2 hunks)backend/apps/slack/commands/sponsors.py(2 hunks)backend/apps/slack/commands/staff.py(2 hunks)backend/apps/slack/commands/users.py(2 hunks)backend/apps/slack/common/handlers/chapters.py(1 hunks)backend/apps/slack/common/handlers/committees.py(1 hunks)backend/apps/slack/common/handlers/contribute.py(1 hunks)backend/apps/slack/common/handlers/projects.py(1 hunks)backend/apps/slack/events/app_home_opened.py(1 hunks)backend/apps/slack/events/member_joined_channel/catch_all.py(1 hunks)backend/apps/slack/events/member_joined_channel/contribute.py(2 hunks)
⛔ Files not processed due to max files limit (5)
- backend/apps/slack/events/member_joined_channel/gsoc.py
- backend/apps/slack/events/team_join.py
- backend/apps/slack/models/event.py
- backend/apps/slack/utils.py
- backend/pyproject.toml
🧰 Additional context used
🧬 Code Definitions (59)
backend/apps/owasp/management/commands/owasp_update_sponsors.py (7)
backend/apps/common/management/commands/algolia_update_synonyms.py (1)
handle(12-24)backend/apps/common/management/commands/algolia_update_replicas.py (1)
handle(11-21)backend/apps/common/management/commands/load_data.py (1)
handle(13-29)backend/apps/common/management/commands/purge_data.py (1)
handle(11-25)backend/apps/common/management/commands/generate_sitemap.py (1)
handle(44-71)backend/apps/owasp/management/commands/add_project_custom_tags.py (1)
handle(30-60)backend/apps/owasp/management/commands/owasp_process_snapshots.py (1)
handle(22-34)
backend/apps/owasp/index/project.py (1)
backend/apps/common/index.py (1)
configure_replicas(145-170)
backend/apps/common/models.py (10)
backend/apps/github/models/label.py (1)
bulk_save(54-56)backend/apps/github/models/issue.py (1)
bulk_save(166-168)backend/apps/github/models/pull_request.py (1)
bulk_save(97-99)backend/apps/github/models/organization.py (1)
bulk_save(62-64)backend/apps/github/models/repository_contributor.py (1)
bulk_save(71-73)backend/apps/github/models/release.py (1)
bulk_save(99-101)backend/apps/owasp/models/chapter.py (1)
bulk_save(172-180)backend/apps/owasp/models/event.py (1)
bulk_save(72-83)backend/apps/owasp/models/project.py (1)
bulk_save(246-254)backend/apps/owasp/models/sponsor.py (1)
bulk_save(74-82)
backend/apps/common/management/commands/algolia_update_synonyms.py (3)
backend/apps/common/management/commands/algolia_update_replicas.py (1)
handle(11-21)backend/apps/common/management/commands/load_data.py (1)
handle(13-29)backend/apps/common/management/commands/purge_data.py (1)
handle(11-25)
backend/apps/common/geocoding.py (1)
backend/apps/common/utils.py (1)
get_nest_user_agent(28-35)
backend/apps/owasp/graphql/queries/stats.py (1)
backend/apps/owasp/graphql/nodes/stats.py (1)
StatsNode(6-12)
backend/apps/owasp/models/snapshot.py (5)
backend/apps/core/models/prompt.py (1)
save(29-39)backend/apps/github/models/issue.py (1)
save(154-163)backend/apps/github/models/pull_request.py (1)
save(92-94)backend/apps/owasp/models/chapter.py (1)
save(155-169)backend/apps/owasp/models/project.py (1)
save(226-237)
backend/apps/common/management/commands/algolia_update_replicas.py (4)
backend/apps/common/management/commands/algolia_update_synonyms.py (1)
handle(12-24)backend/apps/common/management/commands/load_data.py (1)
handle(13-29)backend/apps/common/management/commands/purge_data.py (1)
handle(11-25)backend/apps/owasp/management/commands/owasp_process_snapshots.py (1)
handle(22-34)
backend/apps/slack/events/member_joined_channel/catch_all.py (1)
backend/apps/slack/apps.py (1)
SlackConfig(11-22)
backend/apps/common/management/commands/purge_data.py (16)
backend/apps/common/management/commands/algolia_update_synonyms.py (1)
handle(12-24)backend/apps/common/management/commands/algolia_update_replicas.py (1)
handle(11-21)backend/apps/common/management/commands/load_data.py (1)
handle(13-29)backend/apps/common/management/commands/generate_sitemap.py (1)
handle(44-71)backend/apps/github/management/commands/github_enrich_issues.py (1)
handle(33-75)backend/apps/github/management/commands/github_update_project_related_repositories.py (1)
handle(32-75)backend/apps/github/management/commands/github_update_owasp_organization.py (1)
handle(42-132)backend/apps/owasp/management/commands/add_project_custom_tags.py (1)
handle(30-60)backend/apps/owasp/management/commands/owasp_enrich_chapters.py (1)
handle(26-68)backend/apps/owasp/management/commands/owasp_enrich_committees.py (1)
handle(30-69)backend/apps/owasp/management/commands/owasp_enrich_events.py (1)
handle(26-67)backend/apps/owasp/management/commands/owasp_aggregate_projects.py (1)
handle(20-115)backend/apps/owasp/management/commands/owasp_enrich_projects.py (1)
handle(30-67)backend/apps/owasp/management/commands/owasp_scrape_chapters.py (1)
handle(27-88)backend/apps/owasp/management/commands/owasp_process_snapshots.py (1)
handle(22-34)backend/apps/owasp/management/commands/owasp_scrape_committees.py (1)
handle(27-88)
backend/apps/github/index/release.py (4)
backend/apps/github/index/repository.py (2)
update_synonyms(62-64)get_entities(66-77)backend/apps/github/index/user.py (2)
update_synonyms(68-70)get_entities(72-82)backend/apps/github/index/issue.py (2)
update_synonyms(80-87)get_entities(89-102)backend/apps/common/index.py (1)
reindex_synonyms(219-247)
backend/apps/slack/events/app_home_opened.py (2)
backend/apps/slack/apps.py (1)
SlackConfig(11-22)backend/apps/slack/blocks.py (2)
get_header(34-87)markdown(18-31)
backend/apps/slack/commands/gsoc.py (1)
backend/apps/slack/events/member_joined_channel/gsoc.py (1)
gsoc_handler(19-68)
backend/apps/github/admin.py (2)
backend/apps/github/models/pull_request.py (1)
PullRequest(11-127)backend/apps/github/models/repository.py (1)
Repository(22-333)
backend/apps/github/management/commands/github_enrich_issues.py (1)
backend/apps/owasp/management/commands/owasp_enrich_projects.py (2)
add_arguments(17-28)handle(30-67)
backend/apps/github/common.py (2)
backend/apps/github/models/organization.py (1)
Organization(12-88)backend/apps/github/models/repository.py (1)
Repository(22-333)
backend/apps/slack/commands/contribute.py (1)
backend/apps/slack/events/member_joined_channel/contribute.py (1)
contribute_handler(24-92)
backend/apps/owasp/management/commands/owasp_update_events.py (16)
backend/apps/github/management/commands/github_update_owasp_organization.py (1)
handle(42-132)backend/apps/common/management/commands/algolia_update_synonyms.py (1)
handle(12-24)backend/apps/common/management/commands/algolia_update_replicas.py (1)
handle(11-21)backend/apps/common/management/commands/load_data.py (1)
handle(13-29)backend/apps/common/management/commands/purge_data.py (1)
handle(11-25)backend/apps/common/management/commands/generate_sitemap.py (1)
handle(44-71)backend/apps/github/management/commands/github_enrich_issues.py (1)
handle(33-75)backend/apps/github/management/commands/github_update_project_related_repositories.py (1)
handle(32-75)backend/apps/owasp/management/commands/add_project_custom_tags.py (1)
handle(30-60)backend/apps/owasp/management/commands/owasp_enrich_chapters.py (1)
handle(26-68)backend/apps/owasp/management/commands/owasp_enrich_committees.py (1)
handle(30-69)backend/apps/owasp/management/commands/owasp_enrich_events.py (1)
handle(26-67)backend/apps/owasp/management/commands/owasp_aggregate_projects.py (1)
handle(20-115)backend/apps/owasp/management/commands/owasp_enrich_projects.py (1)
handle(30-67)backend/apps/owasp/management/commands/owasp_scrape_chapters.py (1)
handle(27-88)backend/apps/owasp/management/commands/owasp_process_snapshots.py (1)
handle(22-34)
backend/apps/owasp/management/commands/add_project_custom_tags.py (3)
backend/apps/owasp/management/commands/owasp_scrape_projects.py (1)
add_arguments(22-29)backend/apps/common/management/commands/algolia_update_replicas.py (1)
handle(11-21)backend/apps/owasp/management/commands/owasp_process_snapshots.py (1)
handle(22-34)
backend/apps/owasp/api/search/project.py (1)
backend/apps/owasp/models/project.py (1)
Project(18-279)
backend/apps/slack/events/member_joined_channel/contribute.py (1)
backend/apps/slack/commands/contribute.py (1)
contribute_handler(17-60)
backend/apps/github/index/user.py (4)
backend/apps/github/index/release.py (2)
update_synonyms(56-58)get_entities(60-70)backend/apps/github/index/repository.py (2)
update_synonyms(62-64)get_entities(66-77)backend/apps/github/index/issue.py (2)
update_synonyms(80-87)get_entities(89-102)backend/apps/common/index.py (1)
reindex_synonyms(219-247)
backend/apps/owasp/management/commands/owasp_enrich_committees.py (6)
backend/apps/common/management/commands/algolia_update_synonyms.py (2)
Command(9-24)handle(12-24)backend/apps/common/management/commands/algolia_update_replicas.py (2)
Command(8-21)handle(11-21)backend/apps/common/management/commands/load_data.py (2)
Command(10-29)handle(13-29)backend/apps/common/management/commands/purge_data.py (2)
Command(8-25)handle(11-25)backend/apps/owasp/management/commands/owasp_enrich_projects.py (3)
Command(14-67)add_arguments(17-28)handle(30-67)backend/apps/owasp/management/commands/owasp_scrape_projects.py (1)
add_arguments(22-29)
backend/apps/github/management/commands/github_update_owasp_organization.py (17)
backend/apps/github/management/commands/github_update_project_related_repositories.py (3)
Command(18-75)add_arguments(23-30)handle(32-75)backend/apps/common/management/commands/load_data.py (2)
Command(10-29)handle(13-29)backend/apps/owasp/management/commands/owasp_update_events.py (2)
Command(10-33)handle(13-33)backend/apps/common/management/commands/algolia_update_synonyms.py (2)
Command(9-24)handle(12-24)backend/apps/common/management/commands/algolia_update_replicas.py (2)
Command(8-21)handle(11-21)backend/apps/common/management/commands/purge_data.py (2)
Command(8-25)handle(11-25)backend/apps/github/management/commands/github_enrich_issues.py (3)
Command(13-75)add_arguments(16-31)handle(33-75)backend/apps/owasp/management/commands/add_project_custom_tags.py (3)
Command(12-60)add_arguments(15-28)handle(30-60)backend/apps/owasp/management/commands/owasp_enrich_chapters.py (3)
Command(14-68)add_arguments(17-24)handle(26-68)backend/apps/owasp/management/commands/owasp_enrich_committees.py (3)
Command(14-69)add_arguments(17-28)handle(30-69)backend/apps/owasp/management/commands/owasp_enrich_events.py (3)
Command(14-67)add_arguments(17-24)handle(26-67)backend/apps/owasp/management/commands/owasp_aggregate_projects.py (3)
Command(8-115)add_arguments(11-18)handle(20-115)backend/apps/owasp/management/commands/owasp_enrich_projects.py (3)
Command(14-67)add_arguments(17-28)handle(30-67)backend/apps/owasp/management/commands/owasp_scrape_chapters.py (3)
Command(15-88)add_arguments(18-25)handle(27-88)backend/apps/owasp/management/commands/owasp_process_snapshots.py (2)
Command(19-135)handle(22-34)backend/apps/owasp/management/commands/owasp_scrape_committees.py (1)
add_arguments(18-25)backend/apps/owasp/management/commands/owasp_scrape_projects.py (1)
add_arguments(22-29)
backend/apps/github/graphql/queries/release.py (1)
backend/apps/owasp/graphql/nodes/project.py (1)
resolve_recent_releases(60-62)
backend/apps/github/index/repository.py (4)
backend/apps/github/index/release.py (1)
get_entities(60-70)backend/apps/github/index/user.py (1)
get_entities(72-82)backend/apps/github/index/issue.py (1)
get_entities(89-102)backend/apps/common/index.py (1)
reindex_synonyms(219-247)
backend/apps/owasp/management/commands/owasp_scrape_projects.py (15)
backend/apps/owasp/management/commands/owasp_scrape_chapters.py (3)
Command(15-88)add_arguments(18-25)handle(27-88)backend/apps/owasp/management/commands/owasp_scrape_committees.py (3)
Command(15-88)add_arguments(18-25)handle(27-88)backend/apps/common/management/commands/algolia_update_synonyms.py (2)
Command(9-24)handle(12-24)backend/apps/common/management/commands/algolia_update_replicas.py (2)
Command(8-21)handle(11-21)backend/apps/common/management/commands/load_data.py (2)
Command(10-29)handle(13-29)backend/apps/common/management/commands/purge_data.py (2)
Command(8-25)handle(11-25)backend/apps/github/management/commands/github_enrich_issues.py (3)
Command(13-75)add_arguments(16-31)handle(33-75)backend/apps/github/management/commands/github_update_project_related_repositories.py (3)
Command(18-75)add_arguments(23-30)handle(32-75)backend/apps/github/management/commands/github_update_owasp_organization.py (3)
Command(22-132)add_arguments(27-40)handle(42-132)backend/apps/owasp/management/commands/add_project_custom_tags.py (3)
Command(12-60)add_arguments(15-28)handle(30-60)backend/apps/owasp/management/commands/owasp_enrich_chapters.py (3)
Command(14-68)add_arguments(17-24)handle(26-68)backend/apps/owasp/management/commands/owasp_enrich_committees.py (3)
Command(14-69)add_arguments(17-28)handle(30-69)backend/apps/owasp/management/commands/owasp_enrich_events.py (3)
Command(14-67)add_arguments(17-24)handle(26-67)backend/apps/owasp/management/commands/owasp_aggregate_projects.py (3)
Command(8-115)add_arguments(11-18)handle(20-115)backend/apps/owasp/management/commands/owasp_enrich_projects.py (3)
Command(14-67)add_arguments(17-28)handle(30-67)
backend/apps/owasp/management/commands/owasp_scrape_chapters.py (4)
backend/apps/owasp/management/commands/owasp_scrape_committees.py (3)
Command(15-88)add_arguments(18-25)handle(27-88)backend/apps/owasp/management/commands/owasp_enrich_chapters.py (3)
Command(14-68)add_arguments(17-24)handle(26-68)backend/apps/owasp/management/commands/owasp_enrich_events.py (3)
Command(14-67)add_arguments(17-24)handle(26-67)backend/apps/owasp/management/commands/owasp_enrich_projects.py (3)
Command(14-67)add_arguments(17-28)handle(30-67)
backend/apps/owasp/management/commands/owasp_enrich_projects.py (10)
backend/apps/common/management/commands/algolia_update_synonyms.py (2)
Command(9-24)handle(12-24)backend/apps/common/management/commands/algolia_update_replicas.py (2)
Command(8-21)handle(11-21)backend/apps/common/management/commands/load_data.py (2)
Command(10-29)handle(13-29)backend/apps/common/management/commands/purge_data.py (2)
Command(8-25)handle(11-25)backend/apps/owasp/management/commands/add_project_custom_tags.py (3)
Command(12-60)add_arguments(15-28)handle(30-60)backend/apps/owasp/management/commands/owasp_enrich_chapters.py (3)
Command(14-68)add_arguments(17-24)handle(26-68)backend/apps/owasp/management/commands/owasp_enrich_committees.py (3)
Command(14-69)add_arguments(17-28)handle(30-69)backend/apps/owasp/management/commands/owasp_enrich_events.py (3)
Command(14-67)add_arguments(17-24)handle(26-67)backend/apps/owasp/management/commands/owasp_process_snapshots.py (2)
Command(19-135)handle(22-34)backend/apps/owasp/management/commands/owasp_scrape_projects.py (1)
add_arguments(22-29)
backend/apps/owasp/management/commands/owasp_enrich_chapters.py (16)
backend/apps/common/management/commands/algolia_update_synonyms.py (2)
Command(9-24)handle(12-24)backend/apps/common/management/commands/algolia_update_replicas.py (2)
Command(8-21)handle(11-21)backend/apps/common/management/commands/load_data.py (2)
Command(10-29)handle(13-29)backend/apps/common/management/commands/purge_data.py (2)
Command(8-25)handle(11-25)backend/apps/github/management/commands/github_enrich_issues.py (3)
Command(13-75)add_arguments(16-31)handle(33-75)backend/apps/github/management/commands/github_update_project_related_repositories.py (3)
Command(18-75)add_arguments(23-30)handle(32-75)backend/apps/github/management/commands/github_update_owasp_organization.py (3)
Command(22-132)add_arguments(27-40)handle(42-132)backend/apps/owasp/management/commands/add_project_custom_tags.py (3)
Command(12-60)add_arguments(15-28)handle(30-60)backend/apps/owasp/management/commands/owasp_enrich_committees.py (3)
Command(14-69)add_arguments(17-28)handle(30-69)backend/apps/owasp/management/commands/owasp_enrich_events.py (3)
Command(14-67)add_arguments(17-24)handle(26-67)backend/apps/owasp/management/commands/owasp_aggregate_projects.py (3)
Command(8-115)add_arguments(11-18)handle(20-115)backend/apps/owasp/management/commands/owasp_enrich_projects.py (3)
Command(14-67)add_arguments(17-28)handle(30-67)backend/apps/owasp/management/commands/owasp_scrape_chapters.py (3)
Command(15-88)add_arguments(18-25)handle(27-88)backend/apps/owasp/management/commands/owasp_process_snapshots.py (2)
Command(19-135)handle(22-34)backend/apps/owasp/management/commands/owasp_scrape_committees.py (3)
Command(15-88)add_arguments(18-25)handle(27-88)backend/apps/owasp/management/commands/owasp_scrape_projects.py (1)
add_arguments(22-29)
backend/apps/owasp/management/commands/owasp_aggregate_projects.py (10)
backend/apps/github/management/commands/github_enrich_issues.py (1)
add_arguments(16-31)backend/apps/github/management/commands/github_update_project_related_repositories.py (1)
add_arguments(23-30)backend/apps/github/management/commands/github_update_owasp_organization.py (1)
add_arguments(27-40)backend/apps/owasp/management/commands/owasp_enrich_chapters.py (1)
add_arguments(17-24)backend/apps/owasp/management/commands/owasp_enrich_committees.py (1)
add_arguments(17-28)backend/apps/owasp/management/commands/owasp_enrich_events.py (1)
add_arguments(17-24)backend/apps/owasp/management/commands/owasp_enrich_projects.py (1)
add_arguments(17-28)backend/apps/owasp/management/commands/owasp_scrape_chapters.py (1)
add_arguments(18-25)backend/apps/owasp/management/commands/owasp_scrape_committees.py (1)
add_arguments(18-25)backend/apps/owasp/management/commands/owasp_scrape_projects.py (1)
add_arguments(22-29)
backend/apps/owasp/management/commands/owasp_sync_posts.py (6)
backend/apps/common/management/commands/algolia_update_synonyms.py (1)
handle(12-24)backend/apps/common/management/commands/algolia_update_replicas.py (1)
handle(11-21)backend/apps/common/management/commands/load_data.py (1)
handle(13-29)backend/apps/common/management/commands/purge_data.py (1)
handle(11-25)backend/apps/common/management/commands/generate_sitemap.py (1)
handle(44-71)backend/apps/owasp/management/commands/owasp_process_snapshots.py (1)
handle(22-34)
backend/apps/github/utils.py (2)
backend/apps/github/models/repository.py (1)
url(173-175)backend/apps/github/models/release.py (1)
url(62-64)
backend/apps/owasp/management/commands/owasp_scrape_committees.py (9)
backend/apps/common/management/commands/algolia_update_synonyms.py (2)
Command(9-24)handle(12-24)backend/apps/common/management/commands/algolia_update_replicas.py (2)
Command(8-21)handle(11-21)backend/apps/common/management/commands/load_data.py (2)
Command(10-29)handle(13-29)backend/apps/common/management/commands/purge_data.py (2)
Command(8-25)handle(11-25)backend/apps/owasp/management/commands/add_project_custom_tags.py (3)
Command(12-60)add_arguments(15-28)handle(30-60)backend/apps/owasp/management/commands/owasp_enrich_chapters.py (3)
Command(14-68)add_arguments(17-24)handle(26-68)backend/apps/owasp/management/commands/owasp_enrich_committees.py (3)
Command(14-69)add_arguments(17-28)handle(30-69)backend/apps/owasp/management/commands/owasp_enrich_events.py (3)
Command(14-67)add_arguments(17-24)handle(26-67)backend/apps/owasp/management/commands/owasp_enrich_projects.py (3)
Command(14-67)add_arguments(17-28)handle(30-67)
backend/apps/owasp/management/commands/owasp_process_snapshots.py (15)
backend/apps/common/management/commands/algolia_update_synonyms.py (2)
Command(9-24)handle(12-24)backend/apps/common/management/commands/algolia_update_replicas.py (2)
Command(8-21)handle(11-21)backend/apps/common/management/commands/load_data.py (2)
Command(10-29)handle(13-29)backend/apps/common/management/commands/purge_data.py (2)
Command(8-25)handle(11-25)backend/apps/github/management/commands/github_enrich_issues.py (2)
Command(13-75)handle(33-75)backend/apps/github/management/commands/github_update_project_related_repositories.py (2)
Command(18-75)handle(32-75)backend/apps/github/management/commands/github_update_owasp_organization.py (2)
Command(22-132)handle(42-132)backend/apps/owasp/management/commands/add_project_custom_tags.py (2)
Command(12-60)handle(30-60)backend/apps/owasp/management/commands/owasp_enrich_chapters.py (2)
Command(14-68)handle(26-68)backend/apps/owasp/management/commands/owasp_enrich_committees.py (2)
Command(14-69)handle(30-69)backend/apps/owasp/management/commands/owasp_enrich_events.py (2)
Command(14-67)handle(26-67)backend/apps/owasp/management/commands/owasp_aggregate_projects.py (2)
Command(8-115)handle(20-115)backend/apps/owasp/management/commands/owasp_enrich_projects.py (2)
Command(14-67)handle(30-67)backend/apps/owasp/management/commands/owasp_scrape_chapters.py (2)
Command(15-88)handle(27-88)backend/apps/owasp/management/commands/owasp_scrape_committees.py (2)
Command(15-88)handle(27-88)
backend/apps/github/management/commands/github_update_project_related_repositories.py (16)
backend/apps/github/management/commands/github_update_owasp_organization.py (3)
Command(22-132)add_arguments(27-40)handle(42-132)backend/apps/common/management/commands/algolia_update_synonyms.py (2)
Command(9-24)handle(12-24)backend/apps/common/management/commands/algolia_update_replicas.py (2)
Command(8-21)handle(11-21)backend/apps/common/management/commands/load_data.py (2)
Command(10-29)handle(13-29)backend/apps/common/management/commands/purge_data.py (2)
Command(8-25)handle(11-25)backend/apps/github/management/commands/github_enrich_issues.py (3)
Command(13-75)add_arguments(16-31)handle(33-75)backend/apps/owasp/management/commands/add_project_custom_tags.py (3)
Command(12-60)add_arguments(15-28)handle(30-60)backend/apps/owasp/management/commands/owasp_enrich_chapters.py (3)
Command(14-68)add_arguments(17-24)handle(26-68)backend/apps/owasp/management/commands/owasp_enrich_committees.py (3)
Command(14-69)add_arguments(17-28)handle(30-69)backend/apps/owasp/management/commands/owasp_enrich_events.py (3)
Command(14-67)add_arguments(17-24)handle(26-67)backend/apps/owasp/management/commands/owasp_aggregate_projects.py (3)
Command(8-115)add_arguments(11-18)handle(20-115)backend/apps/owasp/management/commands/owasp_enrich_projects.py (3)
Command(14-67)add_arguments(17-28)handle(30-67)backend/apps/owasp/management/commands/owasp_scrape_chapters.py (3)
Command(15-88)add_arguments(18-25)handle(27-88)backend/apps/owasp/management/commands/owasp_process_snapshots.py (2)
Command(19-135)handle(22-34)backend/apps/owasp/management/commands/owasp_scrape_committees.py (3)
Command(15-88)add_arguments(18-25)handle(27-88)backend/apps/owasp/management/commands/owasp_scrape_projects.py (1)
add_arguments(22-29)
backend/apps/slack/common/handlers/contribute.py (1)
backend/apps/slack/common/presentation.py (1)
EntityPresentation(7-25)
backend/apps/common/management/commands/load_data.py (5)
backend/apps/common/management/commands/algolia_update_synonyms.py (1)
handle(12-24)backend/apps/common/management/commands/algolia_update_replicas.py (1)
handle(11-21)backend/apps/common/management/commands/purge_data.py (1)
handle(11-25)backend/apps/common/management/commands/generate_sitemap.py (1)
handle(44-71)backend/apps/owasp/management/commands/owasp_process_snapshots.py (1)
handle(22-34)
backend/apps/owasp/graphql/nodes/committee.py (2)
backend/apps/github/graphql/nodes/user.py (2)
resolve_created_at(41-43)resolve_issues_count(45-47)backend/apps/owasp/graphql/nodes/project.py (2)
resolve_issues_count(44-46)resolve_repositories_count(68-70)
backend/apps/github/models/pull_request.py (6)
backend/apps/github/models/repository.py (2)
from_github(177-288)update_data(291-333)backend/apps/github/models/user.py (2)
from_github(54-75)update_data(92-113)backend/apps/core/models/prompt.py (1)
save(29-39)backend/apps/owasp/models/snapshot.py (1)
save(42-53)backend/apps/owasp/models/event.py (2)
bulk_save(72-83)update_data(139-161)backend/apps/owasp/models/sponsor.py (2)
bulk_save(74-82)update_data(85-107)
backend/apps/github/models/issue.py (2)
backend/apps/common/open_ai.py (1)
OpenAi(11-102)backend/apps/common/models.py (1)
bulk_save(15-30)
backend/apps/github/models/repository_contributor.py (1)
backend/apps/github/models/repository.py (2)
from_github(177-288)update_data(291-333)
backend/apps/github/models/label.py (3)
backend/apps/github/models/user.py (2)
from_github(54-75)update_data(92-113)backend/apps/github/models/repository.py (2)
from_github(177-288)update_data(291-333)backend/apps/common/models.py (1)
bulk_save(15-30)
backend/apps/owasp/models/committee.py (2)
backend/apps/owasp/models/chapter.py (3)
from_github(77-101)save(155-169)update_data(183-205)backend/apps/owasp/models/project.py (3)
from_github(185-224)save(226-237)update_data(257-279)
backend/apps/owasp/models/chapter.py (7)
backend/apps/owasp/models/committee.py (3)
from_github(34-48)save(50-55)bulk_save(69-71)backend/apps/owasp/models/common.py (1)
from_github(114-127)backend/apps/github/models/repository.py (1)
from_github(177-288)backend/apps/owasp/models/event.py (2)
generate_geo_location(192-206)bulk_save(72-83)backend/apps/core/models/prompt.py (1)
save(29-39)backend/apps/owasp/models/snapshot.py (1)
save(42-53)backend/apps/common/models.py (1)
bulk_save(15-30)
backend/apps/core/models/prompt.py (5)
backend/apps/github/models/issue.py (1)
save(154-163)backend/apps/github/models/pull_request.py (1)
save(92-94)backend/apps/owasp/models/chapter.py (1)
save(155-169)backend/apps/owasp/models/project.py (1)
save(226-237)backend/apps/owasp/models/snapshot.py (1)
save(42-53)
backend/apps/github/models/repository.py (4)
backend/apps/owasp/models/project.py (2)
nest_key(151-153)save(226-237)backend/apps/owasp/models/chapter.py (2)
nest_key(67-69)save(155-169)backend/apps/github/models/release.py (1)
url(62-64)backend/apps/github/models/pull_request.py (1)
save(92-94)
backend/apps/github/models/user.py (2)
backend/apps/github/models/repository.py (2)
from_github(177-288)update_data(291-333)backend/apps/github/models/label.py (2)
from_github(31-51)update_data(59-80)
backend/apps/owasp/models/sponsor.py (4)
backend/apps/common/models.py (1)
bulk_save(15-30)backend/apps/owasp/models/chapter.py (2)
bulk_save(172-180)save(155-169)backend/apps/owasp/models/event.py (1)
bulk_save(72-83)backend/apps/owasp/models/project.py (2)
bulk_save(246-254)save(226-237)
backend/apps/owasp/management/commands/owasp_enrich_events.py (4)
backend/apps/owasp/management/commands/owasp_enrich_chapters.py (3)
Command(14-68)add_arguments(17-24)handle(26-68)backend/apps/owasp/management/commands/owasp_enrich_committees.py (3)
Command(14-69)add_arguments(17-28)handle(30-69)backend/apps/owasp/management/commands/owasp_enrich_projects.py (3)
Command(14-67)add_arguments(17-28)handle(30-67)backend/apps/owasp/management/commands/owasp_scrape_projects.py (1)
add_arguments(22-29)
backend/apps/github/models/release.py (3)
backend/apps/github/models/repository.py (2)
from_github(177-288)update_data(291-333)backend/apps/owasp/models/chapter.py (4)
from_github(77-101)bulk_save(172-180)update_data(183-205)save(155-169)backend/apps/common/models.py (2)
bulk_save(15-30)BulkSaveModel(8-30)
backend/apps/owasp/graphql/nodes/common.py (2)
backend/apps/github/graphql/nodes/user.py (1)
resolve_url(57-59)backend/apps/github/graphql/nodes/repository.py (2)
resolve_url(79-81)resolve_top_contributors(71-73)
backend/apps/owasp/models/event.py (1)
backend/apps/owasp/models/sponsor.py (3)
bulk_save(74-82)update_data(85-107)from_dict(109-151)
backend/apps/owasp/models/mixins/chapter.py (7)
backend/apps/github/models/mixins/release.py (2)
is_indexable(12-14)idx_created_at(33-35)backend/apps/github/models/mixins/repository.py (3)
is_indexable(16-23)idx_created_at(36-38)idx_key(56-58)backend/apps/github/models/mixins/user.py (3)
is_indexable(14-16)idx_created_at(34-36)idx_key(44-46)backend/apps/github/models/mixins/issue.py (2)
is_indexable(8-18)idx_created_at(36-38)backend/apps/owasp/models/mixins/common.py (1)
is_indexable(8-10)backend/apps/owasp/models/mixins/committee.py (2)
idx_created_at(10-12)idx_key(15-17)backend/apps/owasp/models/mixins/project.py (2)
idx_is_active(37-39)idx_key(47-49)
backend/apps/github/models/mixins/release.py (1)
backend/apps/github/models/repository.py (3)
project(150-152)nest_key(140-142)path(145-147)
backend/apps/common/index.py (1)
backend/apps/owasp/index/project.py (1)
configure_replicas(80-95)
backend/apps/github/models/mixins/repository.py (2)
backend/apps/owasp/models/mixins/project.py (6)
idx_contributors_count(22-24)idx_forks_count(32-34)idx_languages(52-54)idx_name(67-69)idx_stars_count(100-102)idx_top_contributors(105-107)backend/apps/github/models/repository.py (2)
nest_key(140-142)project(150-152)
backend/apps/common/management/commands/generate_sitemap.py (17)
backend/apps/github/management/commands/github_enrich_issues.py (2)
add_arguments(16-31)handle(33-75)backend/apps/github/management/commands/github_update_project_related_repositories.py (2)
add_arguments(23-30)handle(32-75)backend/apps/github/management/commands/github_update_owasp_organization.py (2)
add_arguments(27-40)handle(42-132)backend/apps/owasp/management/commands/add_project_custom_tags.py (2)
add_arguments(15-28)handle(30-60)backend/apps/owasp/management/commands/owasp_enrich_chapters.py (2)
add_arguments(17-24)handle(26-68)backend/apps/owasp/management/commands/owasp_enrich_committees.py (2)
add_arguments(17-28)handle(30-69)backend/apps/owasp/management/commands/owasp_enrich_events.py (2)
add_arguments(17-24)handle(26-67)backend/apps/owasp/management/commands/owasp_aggregate_projects.py (2)
add_arguments(11-18)handle(20-115)backend/apps/owasp/management/commands/owasp_enrich_projects.py (2)
add_arguments(17-28)handle(30-67)backend/apps/owasp/management/commands/owasp_scrape_chapters.py (2)
add_arguments(18-25)handle(27-88)backend/apps/owasp/management/commands/owasp_scrape_committees.py (2)
add_arguments(18-25)handle(27-88)backend/apps/owasp/management/commands/owasp_scrape_projects.py (1)
add_arguments(22-29)backend/apps/common/management/commands/algolia_update_synonyms.py (1)
handle(12-24)backend/apps/common/management/commands/algolia_update_replicas.py (1)
handle(11-21)backend/apps/common/management/commands/load_data.py (1)
handle(13-29)backend/apps/common/management/commands/purge_data.py (1)
handle(11-25)backend/apps/owasp/management/commands/owasp_process_snapshots.py (1)
handle(22-34)
backend/apps/owasp/models/mixins/project.py (6)
backend/apps/github/models/mixins/repository.py (6)
idx_contributors_count(31-33)idx_forks_count(46-48)idx_key(56-58)idx_languages(61-63)idx_name(71-73)idx_stars_count(96-98)backend/apps/owasp/models/mixins/chapter.py (3)
idx_is_active(34-36)idx_key(39-41)idx_updated_at(74-76)backend/apps/owasp/models/mixins/committee.py (2)
idx_key(15-17)idx_updated_at(30-32)backend/apps/github/models/mixins/release.py (1)
idx_name(48-50)backend/apps/owasp/models/mixins/common.py (1)
idx_name(23-25)backend/apps/github/models/mixins/issue.py (1)
idx_updated_at(131-133)
🔇 Additional comments (280)
backend/apps/owasp/graphql/queries/stats.py (1)
16-16: Type annotation properly added to improve code clarity.The addition of the return type annotation
-> StatsNodecorrectly specifies that this method returns aStatsNodeobject. This annotation matches both the implementation (line 44 returns a StatsNode instance) and the existing documentation (line 25), enhancing type clarity and supporting static type checking while maintaining the original functionality.backend/apps/github/models/generic_issue_model.py (1)
40-40: Good addition of return type annotation.The added return type annotation to the
__str__method correctly specifies the expected return type asstr, improving type safety and code clarity.backend/apps/owasp/admin.py (1)
131-131: Well-placed return type annotation.The added return type annotation to the
custom_field_namemethod correctly indicates it returns astr, enhancing type clarity without altering the method's functionality.backend/apps/github/index/release.py (3)
3-4: Appropriate import addition for type annotation.Adding the import for
QuerySetis necessary to support the type annotation in theget_entitiesmethod.
56-56: Consistent return type annotation.The added return type annotation
-> Nonecorrectly indicates that this method doesn't return a value, consistent with similar methods in other index files.
60-60: Clear return type specification.The return type annotation
-> QuerySetaccurately reflects that this method returns a Django QuerySet, providing good type clarity.backend/apps/owasp/scraper.py (3)
3-4: Future import for annotations support.Adding the
__future__import for annotations enables forward references in type hints, which is a good practice for more complex type annotations.
13-13: Explicit logger type annotation.The added type annotation for the logger variable correctly specifies it as a
logging.Loggerinstance, enhancing code clarity.
22-22: Comprehensive parameter and return type annotations.The type annotations for the
__init__method parameters and return type provide excellent clarity:
url: bytes | strcorrectly indicates the method accepts either bytes or string input-> Noneproperly indicates the constructor doesn't return a valueThis enhances both code readability and type safety.
backend/apps/github/admin.py (2)
45-45: Type annotations correctly added to custom_field_github_url method.The type annotation for the parameter
obj: PullRequestand return type-> strmatches the documentation and improves type safety.
135-135: Type annotations correctly added to custom_field_title method.The type annotation for the parameter
obj: Repositoryand return type-> strmatches the documentation and improves type safety.backend/apps/github/index/user.py (3)
3-4: Appropriate import added for QuerySet type annotation.The import of
QuerySetfromdjango.db.modelsis correctly added to support the type annotation in theget_entitiesmethod.
68-68: Return type annotation correctly added to update_synonyms method.The
-> Nonereturn type annotation matches the implementation, which doesn't return a value.
72-72: Return type annotation correctly added to get_entities method.The
-> QuerySetreturn type annotation matches the implementation, which returns a Django QuerySet.backend/apps/owasp/management/commands/add_project_custom_tags.py (2)
15-15: Return type annotation correctly added to add_arguments method.The
-> Nonereturn type annotation matches the implementation, which doesn't return a value.
30-30: Return type annotation correctly added to handle method.The
-> Nonereturn type annotation matches the implementation, which has early returns without values.backend/apps/github/common.py (2)
19-19: Type annotation correctly added to logger variable.The type annotation
logging.Loggermatches the initialized value and improves type safety.
22-24: Return type annotation correctly added to sync_repository function.The return type annotation
-> tuple[Organization, Repository]matches the function's implementation, which returns these two types at line 166. The improved formatting also enhances readability.backend/apps/github/utils.py (6)
3-4: Nice addition of future annotations!Good practice to include the
from __future__ import annotationsat the beginning of the file. This allows for forward references in type annotations, which is especially useful when referring to a class within its own definition.
13-13: Good type annotation for loggerAdding explicit type annotation for the logger variable improves code clarity and helps with static type checking.
60-63: Well-defined type annotations for the repository file content functionThe type annotations for the parameters and return type are accurate and comprehensive:
url: stris appropriate for a URL parameter- The timeout parameter's type annotation correctly captures all possible timeout formats for requests
- Return type
str | Noneproperly indicates the function can return either a string or None
78-78: Good explicit return in exception handlerAdding an explicit
return Nonein the exception handler improves code clarity and makes the function's behavior more explicit.
81-81: Appropriate type annotations for repository path functionThe parameter and return type annotations are clear and accurate.
95-95: Well-structured type annotation with keyword-only parameterGood use of the asterisk to make
check_patha keyword-only parameter, which improves readability when calling the function. The return type annotation is also accurate.backend/apps/owasp/models/post.py (3)
29-29: Correct return type annotation for bulk_saveAdding
-> Noneas the return type correctly indicates that this method doesn't return a value.
39-39: Well-structured update_data signature with keyword-only parameterGood improvements to this method:
- Making
savea keyword-only parameter with*,enforces more readable code when the method is called- The type annotation for the parameter is clear
- The return type annotation correctly indicates the method returns a Post instance
54-54: Appropriate return type annotation for from_dictAdding
-> Noneas the return type correctly indicates that this method doesn't return a value.backend/apps/github/models/repository.py (6)
140-140: Clear return type for nest_key propertyAdding the
-> strreturn type annotation clearly indicates the property returns a string.
145-145: Clear return type for path propertyAdding the
-> strreturn type annotation clearly indicates the property returns a string.
164-164: Appropriate return type for top_languages propertyAdding the
-> list[str]return type annotation accurately reflects that this property returns a list of strings.
173-173: Clear return type for url propertyAdding the
-> strreturn type annotation clearly indicates the property returns a string.
185-185: Helpful return type for from_github methodAdding the
-> Nonereturn type annotation makes it clear that this method doesn't return a value.
298-300: Well-structured update_data signature with keyword-only parameterGood improvements to this method:
- Making
savea keyword-only parameter with*,enforces more readable code when the method is called- The type annotation for the parameter is clear
- The return type annotation correctly uses a forward reference to indicate the method returns a Repository instance
backend/apps/owasp/models/sponsor.py (5)
59-59: Appropriate return type for str methodAdding the
-> strreturn type annotation correctly indicates this method returns a string.
64-64: Clear return type for readable_member_type propertyAdding the
-> strreturn type annotation clearly indicates the property returns a string.
69-69: Clear return type for readable_sponsor_type propertyAdding the
-> strreturn type annotation clearly indicates the property returns a string.
85-85: Well-structured update_data signature with keyword-only parameterGood improvements to this method:
- Adding type annotation for the
dataparameter- Making
savea keyword-only parameter with*,enforces more readable code when the method is called- The return type annotation correctly uses a forward reference to indicate the method returns a Sponsor instance
109-109: Appropriate type annotations for from_dict methodAdding the parameter type annotation and return type annotation improves code clarity.
backend/apps/core/validators.py (4)
9-9: Type annotations improve code clarity.The addition of proper type hints (
str -> None) enhances code readability and enables static type checking.
33-33: Type annotations improve code clarity.The parameter and return type annotations correctly specify that this function takes an integer and doesn't return a value.
73-73: Type annotations improve code clarity.The parameter and return type annotations correctly specify that this function takes a string and doesn't return a value.
113-113: Type annotations improve code clarity.The parameter and return type annotations correctly specify that this function takes a dictionary and doesn't return a value.
backend/apps/owasp/models/mixins/chapter.py (2)
10-10: Type annotations improve code clarity.The added return type annotation correctly specifies that this property returns a boolean value.
19-19: Type annotations systematically applied to property methods.The added return type annotations correctly specify the expected return types for these properties, enhancing code clarity and enabling static type checking.
Also applies to: 24-24, 29-29, 34-34, 39-39, 44-44, 49-49, 54-54
backend/apps/core/models/prompt.py (2)
11-11: Type annotation on logger improves clarity.The type annotation correctly specifies the logger variable as a
logging.Loggerinstance.
29-29: Return type annotation on save method is correct.The added return type annotation correctly specifies that the method doesn't return a value.
backend/apps/owasp/models/mixins/project.py (4)
3-3: Good use of future annotations import.This import ensures that string forward references in type annotations are supported, which is especially important when dealing with self-referential types.
17-17: Type annotations systematically applied to property methods.The added return type annotations correctly specify the expected return types for these properties, enhancing code clarity and enabling static type checking.
Also applies to: 22-22, 27-27, 32-32, 37-37, 47-47, 57-57, 67-67, 72-72, 95-95, 100-100, 110-110
62-62: Union type annotation is correctly used.The
float | Nonetype correctly specifies that this method returns either a float or None, which is consistent with the method implementation.
115-115: Union type for idx_updated_at correctly handles multiple return types.The
str | floattype correctly specifies that this method returns either a string or a float, which is consistent with the method implementation.backend/apps/github/models/mixins/repository.py (3)
3-3: Import ofAnyfromtypingfor improved type annotations.The addition of the
Anyimport from the typing module supports the new type annotations in the file, particularly for the complex type annotation inidx_top_contributors.
26-28: Type annotations for property methods improve type safety and readability.The addition of return type annotations for these property methods enhances code readability and enables better static type checking. The types chosen accurately reflect the expected return values of each property.
Also applies to: 31-33, 36-38, 41-43, 46-48, 51-53, 56-58, 61-63, 66-68, 71-73, 76-78, 81-83, 86-88, 91-93, 96-98, 101-103
106-124: Appropriate complex type annotation foridx_top_contributors.The type annotation
list[dict[str, Any]]correctly captures the structure of the return value - a list of dictionaries with string keys and values of various types.backend/apps/common/geocoding.py (1)
6-6: Import ofLocationfor proper return type annotation.The addition of the
Locationimport is necessary to support the return type annotation in theget_location_coordinatesfunction.backend/apps/owasp/index/project.py (1)
80-80: Added return type annotation toconfigure_replicasstatic method.The addition of the
-> Nonereturn type annotation correctly indicates that this method doesn't return a value. This enhances code readability and improves type safety.backend/apps/slack/commands/sponsor.py (1)
4-4: Import ofWebClientfor proper type annotation.The addition of the
WebClientimport fromslack_sdksupports the type annotation for theclientparameter in thesponsor_handlerfunction.backend/apps/common/models.py (1)
14-15: Good addition of return type annotation!Adding the
-> Nonereturn type annotation to thebulk_savemethod enhances code clarity by explicitly indicating that the method doesn't return any value. This is consistent with how the method is used across the codebase in various model implementations.backend/apps/common/management/commands/purge_data.py (1)
11-11: Appropriate return type annotation for Django command handler.The
-> Nonereturn type annotation on thehandlemethod is correct and consistent with other management commands in the codebase. This improves type safety and makes the interface clearer.backend/apps/owasp/models/project_health_metrics.py (1)
65-65: Correct return type annotation for__str__method.Adding the
-> strreturn type annotation to the__str__method properly indicates that this method returns a string representation of the object, which improves type safety and readability.backend/apps/slack/commands/board.py (2)
4-4: Appropriate import for WebClient type.Adding the explicit import of
WebClientfromslack_sdkis necessary to support the type annotation on theclientparameter in theboard_handlerfunction.
14-14: Good parameter and return type annotations.The type annotations added to the
board_handlerfunction provide clear type information:
command: dict- Properly types the Slack command payloadclient: WebClient- Correctly specifies the Slack client type-> None- Accurately indicates the function doesn't return a valueThese annotations align with the function's implementation and improve type safety.
backend/apps/owasp/models/project_health_requirements.py (1)
55-55: Type annotation correctly applied to__str__method.The addition of the return type annotation
-> strto the__str__method properly indicates that this method returns a string value, enhancing type safety and code clarity.backend/apps/slack/commands/users.py (2)
4-4: Import added to support type annotation.The import of
WebClientfromslack_sdkis necessary to use it in the type annotation of theclientparameter in theusers_handlerfunction.
14-14: Type annotations correctly applied to function signature.The addition of type annotations for
command: dict,client: WebClient, and return type-> Noneproperly describes the parameter types and return type of the function, improving type safety and code readability. This is consistent with the docstring description.backend/apps/owasp/models/snapshot.py (1)
42-42: Return type annotation correctly applied tosavemethod.The addition of the return type annotation
-> Noneto thesavemethod properly indicates that this method doesn't return a value. This is consistent with similarsavemethod implementations across the codebase.backend/apps/owasp/management/commands/owasp_update_sponsors.py (1)
13-13: Return type annotation looks goodThe addition of the
-> Nonereturn type annotation is correct for this method that doesn't return a value. This enhances type safety and code clarity, aligning with similar changes across other command handlers in the codebase.backend/apps/common/management/commands/algolia_update_synonyms.py (1)
12-12: Return type annotation is appropriateThe addition of the
-> Nonereturn type annotation correctly specifies that this method doesn't return a value. This enhances code clarity and enables better static type checking, consistent with the changes in other command handlers.backend/apps/common/management/commands/algolia_update_replicas.py (1)
11-11: Return type annotation looks goodThe addition of the
-> Nonereturn type annotation correctly indicates that this method doesn't return a value. This is consistent with similar changes to other command handlers and improves type safety and code clarity.backend/apps/common/management/commands/load_data.py (1)
13-13: Type annotation addition looks good!The addition of the return type annotation
-> Nonefor thehandlemethod is correct and consistent with similar changes made across other command files. This improves type safety and code readability without changing functionality.backend/apps/slack/actions/home.py (3)
5-5: Appropriate import added for type annotationThe import of
WebClientfromslack_sdkis necessary and correctly added to support the type annotation in the function signature.
27-27: Logger type annotation added correctlyAdding the type annotation
logging.Loggerfor the logger variable improves type safety and clarity.
30-30: Function signature type annotations look goodThe type annotations for the
clientparameter asWebClientand the function return type asNoneare correctly implemented and align with the function's behavior.backend/apps/slack/commands/community.py (2)
4-4: Appropriate import added for type annotationThe import of
WebClientfromslack_sdkis necessary and correctly added to support the type annotation in the function signature.
14-14: Function signature type annotations look goodThe type annotations for the
commandparameter asdict, theclientparameter asWebClient, and the function return type asNoneare correctly implemented and align with the function's behavior and documentation.backend/apps/slack/commands/contact.py (2)
4-4: Good addition of the WebClient import for type annotations.Adding the WebClient import is necessary to support the new type annotations and improves the module's self-containment.
14-14: Well-implemented type annotations that match the docstring.The type annotations you've added for the parameters and return type match the descriptions in the docstring perfectly, making the function signature more explicit and enabling static type checking without changing any functionality.
backend/apps/slack/events/member_joined_channel/catch_all.py (2)
3-4: Good addition of WebClient import.The import of WebClient is correctly added and placed on its own line, ensuring good readability.
9-9: Well-implemented type annotations that align with the docstring.The type annotations for
event,client, and the return type match the docstring descriptions and enhance the function's type safety without altering its behavior..pre-commit-config.yaml (1)
29-38: Great addition of mypy for type checking!Adding mypy to the pre-commit hooks is an excellent complement to the type annotations being added throughout the codebase. The configuration is well-structured with appropriate exclusions for test files and using a dedicated configuration file.
backend/apps/owasp/management/commands/owasp_update_events.py (1)
13-13: Return type annotation correctly addedThe addition of
-> Nonereturn type annotation is appropriate for this command handler method and is consistent with other similar command handlers in the codebase.backend/apps/slack/commands/leaders.py (1)
4-4: Added import for WebClient typeGood addition of the specific import for the WebClient type used in the function signature.
backend/apps/owasp/api/search/issue.py (1)
10-17:❓ Verification inconclusive
Improve type specificity and consider backward compatibility
The addition of type annotations is good, but there are two considerations:
- The
attributesparameter could benefit from a more specific type annotation- Adding keyword-only arguments (with
*) could potentially break existing code if callers are using positional argumentsConsider the following improvements:
+from typing import List, Optional + def get_issues( query: str, - attributes: list = None, + attributes: Optional[List[str]] = None, *, distinct: bool = False, limit: int = 25, page: int = 1, ) -> dict:Additionally, verify that all callers of this function are using keyword arguments for
distinct,limit, andpageto ensure the change to keyword-only parameters doesn't break existing code.
🏁 Script executed:
#!/bin/bash # Find all calls to get_issues function to check if they use keyword arguments rg "get_issues\(" --type py -A 10 -B 5Length of output: 4373
Enhance Type Specificity & Verify Keyword-Only Usage
The proposed changes update the
attributesparameter to use a more specific type annotation while introducing keyword-only parameters fordistinct,limit, andpage. For clarity and improved type safety, please refactor as follows:+from typing import List, Optional + def get_issues( query: str, - attributes: list = None, + attributes: Optional[List[str]] = None, *, distinct: bool = False, limit: int = 25, page: int = 1, ) -> dict:Before finalizing this update, please double-check that all calls to
get_issuespass values fordistinct,limit, andpageas keyword arguments. For example, the invocations in:
- backend/tests/apps/owasp/api/search/issue_test.py (e.g.,
result = get_issues(query, page=page, distinct=False))- backend/apps/slack/common/handlers/contribute.py (e.g.,
get_issues(search_query, attributes=attributes, limit=limit, page=page))are already using keyword arguments. Also, verify any test data (such as the tuple
("security", 1, MOCKED_HITS)) isn’t indirectly leading to positional calls that could break the function signature change.backend/apps/owasp/api/search/chapter.py (1)
8-14: Type annotations look good!The type annotations added to
get_chaptersfunction parameters and return type match the function's docstring descriptions. The annotations enhance code readability and will help with static type checking.backend/apps/slack/events/app_home_opened.py (2)
6-6: Appropriate import added for type annotationThe WebClient import has been correctly added to support the type annotation in the function signature.
13-13: Good logger type annotationAdding the explicit Logger type for the logger variable improves code clarity.
backend/apps/slack/commands/policies.py (1)
4-4: Appropriate import added for type annotationThe WebClient import has been correctly added to support the type annotation in the function signature.
backend/apps/slack/commands/news.py (1)
4-4: Appropriate import added for type annotationThe WebClient import has been correctly added to support the type annotation in the function signature.
backend/apps/slack/commands/staff.py (2)
4-4: Correct import addition for type annotation.The import of
WebClientfromslack_sdkis correctly added to support the type annotation in the function signature.
14-14: Well-implemented type annotations.The function signature has been properly updated with type annotations that accurately match the parameter descriptions in the docstring. The return type annotation of
Noneis also appropriate since this function doesn't return any value.backend/apps/slack/commands/owasp.py (2)
4-4: Correct import addition for type annotation.The import of
WebClientfromslack_sdkis correctly added to support the type annotation in the function signature.
15-15: Well-implemented type annotations.The function signature has been properly updated with type annotations that accurately match the parameter descriptions in the docstring. The return type annotation of
Noneis also appropriate since this function doesn't return any value.backend/apps/slack/commands/sponsors.py (1)
4-4: Correct import addition for type annotation.The import of
WebClientfromslack_sdkis correctly added to support the type annotation in the function signature.backend/apps/slack/commands/contribute.py (2)
4-4: Correct import addition for type annotation.The import of
WebClientfromslack_sdkis correctly added to support the type annotation in the function signature.
17-17: Well-implemented type annotations.The function signature has been properly updated with type annotations that accurately match the parameter descriptions in the docstring. The return type annotation of
Noneis also appropriate since this function doesn't return any value.These changes are consistent with the type annotations already present in other parts of the codebase, such as in the
contribute_handlerfunction in the events module.backend/apps/github/index/repository.py (3)
3-3: LGTM! Appropriate import for type annotations.Adding the QuerySet import properly supports the type annotation added to get_entities method.
62-62: LGTM! Proper return type annotation.The -> None annotation correctly indicates that this method doesn't return a value, improving type safety.
66-66: LGTM! Appropriate return type annotation.The -> QuerySet annotation accurately reflects the return type of this method and aligns with similar annotations in other index classes.
backend/apps/slack/commands/projects.py (2)
4-4: LGTM! Appropriate import for type annotations.Adding the WebClient import properly supports the type annotation added to the client parameter.
14-14: LGTM! Clear and accurate type annotations.The parameter and return type annotations correctly specify that command is a dict, client is a WebClient, and the function returns None. These annotations improve type safety and code clarity.
backend/apps/slack/commands/committees.py (2)
4-4: LGTM! Appropriate import for type annotations.Adding the WebClient import properly supports the type annotation added to the client parameter.
14-14: LGTM! Clear and accurate type annotations.The parameter and return type annotations correctly specify that command is a dict, client is a WebClient, and the function returns None. These annotations improve type safety and code clarity.
backend/apps/slack/common/handlers/projects.py (1)
17-22: Solid type annotation additionsThe addition of type hints to the
get_blocksfunction signature improves code clarity and enables better type checking. The parameter types match their default values and intended usage described in the docstring. The return type annotation correctly identifies that the function returns a list.backend/apps/slack/commands/chapters.py (2)
4-4: Good addition of WebClient importThe import of
WebClientfromslack_sdkis necessary to support the type annotation added to theclientparameter in the function signature.
17-17: Well-structured type annotationsThe type annotations added to the
chapters_handlerfunction signature properly document the expected parameter types and return value. Thecommand: dictandclient: WebClientannotations match the parameter descriptions in the docstring, and the-> Nonereturn type correctly indicates the function doesn't return a value.backend/apps/slack/commands/events.py (2)
4-4: Good addition of WebClient importAdding the
WebClientimport fromslack_sdkis necessary to support the type annotation in the function signature.
14-14: Well-implemented type annotationsThe addition of type annotations to the
events_handlerfunction signature properly specifies parameter and return types, improving code clarity and enabling better type checking.backend/apps/slack/commands/jobs.py (3)
4-4: Appropriate WebClient importThe addition of the
WebClientimport fromslack_sdkis necessary to support the type annotation in the function signature.
15-15: Well-structured type annotationsThe type annotations added to the
jobs_handlerfunction signature properly document the expected parameter types and return value. This improves code clarity and enables better type checking.
18-22: Docstring matches type annotationsThe docstring already specifies that
clientis of typeslack_sdk.WebClient, which aligns well with the new type annotation. This consistency is excellent.backend/apps/owasp/management/commands/owasp_enrich_committees.py (3)
11-11: LGTM: Logger type annotation added.Correctly annotated the logger variable with its type.
17-17: LGTM: Return type annotation added.The
Nonereturn type annotation for theadd_argumentsmethod is accurate and consistent with similar command files.
30-30: LGTM: Return type annotation added.The
Nonereturn type annotation for thehandlemethod is accurate and consistent with similar command files.backend/apps/slack/events/member_joined_channel/contribute.py (3)
6-6: Type import added correctly for WebClient.The import for
WebClienthas been properly added to support the type annotation in the function signature below.
21-21: Type annotation properly added to logger.The
logging.Loggertype annotation provides better clarity and enables static type checking for the logger variable.
24-24: Function signature correctly updated with type annotations.The function signature now includes the appropriate type hints, specifying that
clientis aWebClientinstance and the function returnsNone. This matches the existing docstring description and improves type safety.backend/apps/github/models/common.py (3)
34-34: Property method correctly annotated with return type.The
titleproperty method now explicitly indicates it returns a string, which enhances type clarity.
39-39: Property method correctly annotated with return type.The
urlproperty method now explicitly indicates it returns a string, which enhances type clarity.
43-43: Method correctly annotated with return type.The
from_githubmethod now explicitly indicates it returnsNone, which properly represents that this method updates object state without returning a value.backend/apps/github/graphql/queries/release.py (2)
4-4: Import correctly updated to include QuerySet.The import has been properly extended to include
QuerySet, which is now used in the method's return type annotation.
21-23:❓ Verification inconclusive
Method signature updated with type annotations and keyword-only parameter.
The method signature has been enhanced with proper type annotations, specifying
limitas anintand the return type asQuerySet. Additionally,distinctis now marked as a keyword-only parameter with the*notation.This is a potential breaking change if there are existing calls that pass
distinctas a positional argument rather than a keyword argument.
🏁 Script executed:
#!/bin/bash # Check if there are any calls to resolve_recent_releases that might break with the new signature # Look for any calls to resolve_recent_releases with a third positional argument rg -p "resolve_recent_releases\([^,]*,[^,]*,[^,]*,[^=]" --type pyLength of output: 67
Action Required: Verify Method Call Consistency for Updated Signature
The method signature in
backend/apps/github/graphql/queries/release.py(lines 21-23) has been updated with type annotations and a keyword-only parameter fordistinct, which could be a breaking change if any call sites passdistinctpositionally. Our automated search using the provided regex did not return any matching call sites, suggesting that there are likely no affected calls. However, the absence of output raises concerns about the quality of the inference.
- File:
backend/apps/github/graphql/queries/release.py(lines 21-23)- Change: Updated
resolve_recent_releasessignature to:def resolve_recent_releases( root, info, limit: int, *, distinct: bool = False, login=None ) -> QuerySet:- Potential Issue: Calls that pass
distinctpositionally may break.- Verification: No instances of such calls were found via our regex search, but please verify manually that all invocations explicitly pass
distinctas a keyword argument.Please confirm this manually to ensure the update does not introduce any breaking changes.
backend/apps/slack/commands/gsoc.py (2)
4-4: Type import added correctly for WebClient.The import for
WebClienthas been properly added to support the type annotation in the function signature below.
21-21: Function signature correctly updated with type annotations.The function signature now includes the appropriate type hints, specifying that
commandis adict,clientis aWebClientinstance, and the function returnsNone. This matches the existing docstring description and improves type safety.backend/apps/github/management/commands/github_enrich_issues.py (3)
10-10: Type annotation added to logger variableGood addition of type annotation for the logger variable, improving type clarity without affecting functionality.
16-16: Return type annotation added to add_arguments methodGood addition of return type annotation to explicitly indicate that this method returns None. The annotated return type matches the method's behavior.
33-33: Return type annotation added to handle methodGood addition of return type annotation to explicitly indicate that this method returns None. This helps with code clarity and static type checking.
backend/apps/owasp/management/commands/owasp_scrape_projects.py (3)
16-16: Type annotation added to logger variableGood addition of type annotation for the logger variable, improving type clarity without affecting functionality.
22-22: Return type annotation added to add_arguments methodGood addition of return type annotation to explicitly indicate that this method returns None. The annotated return type matches the method's behavior.
31-31: Return type annotation added to handle methodGood addition of return type annotation to explicitly indicate that this method returns None. This helps with code clarity and static type checking.
backend/apps/owasp/api/search/project.py (1)
3-4: Added future import for annotationsGood addition of the future import to support forward references in type hints, which helps with potential circular imports.
backend/apps/owasp/management/commands/owasp_enrich_chapters.py (3)
11-11: Type annotation added to logger variableGood addition of type annotation for the logger variable, improving type clarity without affecting functionality.
17-17: Return type annotation added to add_arguments methodGood addition of return type annotation to explicitly indicate that this method returns None. The annotated return type matches the method's behavior.
26-26: Return type annotation added to handle methodGood addition of return type annotation to explicitly indicate that this method returns None. This helps with code clarity and static type checking.
backend/apps/owasp/management/commands/owasp_aggregate_projects.py (2)
11-11: Type annotation correctly added.The return type annotation of
Noneis appropriate here since the method does not return a value.
20-20: Type annotation correctly added.The return type annotation of
Noneis appropriate for thehandlemethod since it performs operations but doesn't return a value.backend/apps/owasp/management/commands/owasp_update_project_health_requirements.py (2)
87-87: Type annotation correctly added.The return type annotation of
Noneis appropriate here since the method doesn't return a value.
118-118: Type annotation correctly added.The return type annotation of
Noneis appropriate for thehandlemethod since it performs operations but doesn't return a value.backend/apps/github/models/user.py (3)
25-25: Type annotation correctly added.The return type annotation of
stris appropriate for the__str__method as it returns a string representation of the user.
54-54: Type annotation correctly added.The return type annotation of
Noneis appropriate since this method updates instance attributes but doesn't return a value.
92-92: Type annotation correctly added with improved parameter definition.The changes include:
- Adding return type annotation
-> "User"using forward reference- Making
savea keyword-only parameter with*- Adding type annotation for the
saveparameterThese changes enhance type safety and API usage clarity.
backend/apps/github/management/commands/github_update_owasp_organization.py (3)
19-19: Variable type annotation correctly added.Adding the type annotation
: logging.Loggerfor the logger variable enhances code clarity and type safety.
27-27: Type annotation correctly added.The return type annotation of
Noneis appropriate here since the method doesn't return a value.
42-42: Type annotation correctly added.The return type annotation of
Noneis appropriate for thehandlemethod since it performs operations but doesn't return a value.backend/apps/slack/common/handlers/contribute.py (1)
15-20: Type annotations correctly added to function signatureThe addition of type annotations to the
get_blocksfunction parameters and return type improves code clarity and maintainability. The use of the pipe operator (|) for Union types is a good modern Python practice.backend/apps/owasp/management/commands/owasp_scrape_chapters.py (3)
12-12: Logger type annotation added correctlyThe addition of the type annotation for the logger variable improves code clarity and helps with static type checking.
18-18: Return type annotation added for add_arguments methodThe explicit return type of
Noneaccurately reflects that this method doesn't return a value.
27-27: Return type annotation added for handle methodThe explicit return type of
Noneaccurately reflects that this method doesn't return a value, consistent with other similar command classes in the codebase.backend/apps/github/models/label.py (2)
31-31: Return type annotation added for from_github methodThe explicit return type of
Noneaccurately reflects that this method doesn't return a value.
54-54: Return type annotation added for bulk_save methodThe explicit return type of
Noneaccurately reflects that this method doesn't return a value, consistent with the implementation in the parent class.backend/apps/slack/apps.py (4)
6-6: WebClient import added for type annotationsThe import of
WebClientfromslack_sdkis necessary for the type annotations added to thelog_eventsfunction.
8-8: Logger type annotation added correctlyThe addition of the type annotation for the logger variable improves code clarity and helps with static type checking.
28-28: Return type annotation added for error_handler functionThe explicit return type of
Noneaccurately reflects that this function doesn't return a value.
41-43: Type annotations added to log_events function signatureThe addition of type annotations for all parameters (
client: WebClient,context: dict,logger: logging.Logger,payload: dict) and the return type (-> None) improves code clarity and type safety.backend/apps/owasp/management/commands/owasp_enrich_projects.py (3)
11-11: Type annotation for logger variable looks good.Adding the explicit
logging.Loggertype annotation improves code clarity and supports static type checking.
17-17: LGTM: Return type annotation for add_arguments method.The
-> Nonereturn type accurately specifies that this method doesn't return a value, which is consistent with other command classes.
30-30: LGTM: Return type annotation for handle method.The
-> Nonereturn type accurately specifies that this method doesn't return a value, which is consistent with other Django management commands.backend/apps/owasp/management/commands/owasp_sync_posts.py (3)
16-16: LGTM: Type annotations for get_author_image_url method.Both parameter and return type annotations for this method are correctly specified as
strbased on its implementation.
28-28: LGTM: Type annotations for get_blog_url method.The
strparameter and return type annotations accurately reflect the function's behavior.
53-53: LGTM: Return type annotation for handle method.The
-> Nonereturn type accurately specifies that this method doesn't return a value, consistent with Django management commands.backend/apps/core/api/algolia.py (5)
3-4: LGTM: Added future annotations import.Adding
from __future__ import annotationsenables forward references in type hints, which is good practice for more flexible annotations.
6-6: LGTM: Added Any type import.The
Anytype is required for the return type annotation ofget_search_results.
13-13: LGTM: Updated HTTP-related imports.Added specific Django HTTP objects needed for type annotations.
24-31: LGTM: Type annotations for get_search_results function.The parameter and return type annotations accurately reflect the function's signature and return value. Using
dict[str, Any]correctly specifies the return type structure.
67-67: LGTM: Type annotations for algolia_search function.The function parameter is correctly typed as
HttpRequestand the union return typeJsonResponse | HttpResponseNotAllowedaccurately reflects the possible return values.backend/apps/owasp/management/commands/owasp_enrich_events.py (3)
11-11: Type annotation for logger variable looks good.Adding the explicit
logging.Loggertype annotation improves code clarity and supports static type checking.
17-17: LGTM: Return type annotation for add_arguments method.The
-> Nonereturn type accurately specifies that this method doesn't return a value, which is consistent with similar command classes.
26-26: LGTM: Return type annotation for handle method.The
-> Nonereturn type accurately specifies that this method doesn't return a value, which is consistent with Django management command patterns.backend/apps/owasp/management/commands/owasp_scrape_committees.py (3)
12-12: Good type annotation for logger.Adding the type annotation for the logger variable improves code clarity and helps with static type checking.
18-18: Proper return type annotation for add_arguments method.The
-> Nonereturn type annotation correctly specifies that this method doesn't return a value, which is consistent with other command classes in the codebase.
27-27: Appropriate return type annotation for handle method.The
-> Nonereturn type annotation correctly indicates that this method doesn't return a value, matching the implementation pattern across other Django management commands.backend/apps/owasp/management/commands/owasp_process_snapshots.py (3)
16-16: Good type annotation for logger.Adding the
logging.Loggertype annotation to the logger variable improves code clarity and enables better static type checking.
22-22: Proper return type annotation for handle method.The
-> Nonereturn type annotation correctly specifies that this method doesn't return a value, consistent with other management commands.
36-36: Appropriate return type annotation for process_snapshots method.The
-> Nonereturn type annotation correctly indicates that this method doesn't return a value.backend/apps/slack/blocks.py (3)
3-6: Good imports for type annotations.The addition of
from __future__ import annotationsandfrom typing import Anyprovides the necessary imports for the type annotations used in this file.
8-8: Precise return type annotation for divider function.The
-> dict[str, str]return type accurately specifies that this function returns a dictionary with string keys and values.
18-18: Good parameter and return type annotations for markdown function.The parameter type annotation for
textand return type annotation for the function provide clear typing information.backend/apps/common/open_ai.py (3)
8-8: Good type annotation for logger.Adding the type annotation for the logger variable improves code clarity and helps with static type checking.
14-16: Thorough parameter and return type annotations for init.The type annotations for all parameters and the return type provide comprehensive type information.
34-34: Good parameter and return type annotations for set_input.The parameter type annotation for
contentand the return type annotation using the forward reference to"OpenAi"are appropriate.backend/apps/github/models/repository_contributor.py (3)
41-51: Type annotation for str method looks correct.The addition of the
-> strreturn type annotation correctly specifies that this method returns a string, which aligns with its implementation returning a formatted string.
53-69: Proper return type annotation for from_github method.The addition of the
-> Nonereturn type annotation is appropriate as this method modifies the instance in-place without returning a value.
71-73: Return type annotation for bulk_save is consistent.The addition of the
-> Nonereturn type annotation is appropriate as this method delegates toBulkSaveModel.bulk_saveand doesn't return a value.backend/apps/github/models/organization.py (4)
27-34: Type annotation for str method looks correct.The addition of the
-> strreturn type annotation correctly specifies that this method returns a string, which aligns with the method's implementation.
36-53: Proper return type annotation for from_github method.The addition of the
-> Nonereturn type annotation is appropriate as this method modifies the instance in-place without returning a value.
62-64: Return type annotation for bulk_save is consistent.The addition of the
-> Nonereturn type annotation is appropriate as this method delegates toBulkSaveModel.bulk_saveand doesn't return a value.
67-88: Type annotations for update_data method are correct and consistent.The changes to this method are well-implemented:
- Making
savea keyword-only parameter with type annotation- Adding the
-> "Organization"return type annotationThis matches the pattern used in similar methods in other model classes.
backend/apps/core/utils/index.py (1)
10-121: Type annotations for get_params_for_index function look correct.The addition of parameter type annotation
index_name: strand return type annotation-> dictaccurately reflects the function's behavior.backend/apps/github/models/pull_request.py (4)
58-91: Proper return type annotation for from_github method.The addition of the
-> Nonereturn type annotation is appropriate as this method modifies the instance in-place without returning a value.
92-95: Type annotation for save method is consistent with other models.The addition of the
-> Nonereturn type annotation on the save method is appropriate and matches the pattern used in similar methods in other models (like those inapps/core/models/prompt.pyandapps/owasp/models/snapshot.py).
97-99: Return type annotation for bulk_save is consistent.The addition of the
-> Nonereturn type annotation is appropriate as this method delegates toBulkSaveModel.bulk_saveand doesn't return a value.
102-127: Type annotations for update_data method are correct and consistent.The changes to this method are well-implemented:
- Making
savea keyword-only parameter with type annotation- Adding the
-> "PullRequest"return type annotationThis matches the pattern used in similar methods in other model classes like
RepositoryandUser.backend/apps/owasp/graphql/nodes/common.py (5)
21-21: LGTM: Added return type annotation.The type annotation correctly specifies that this method returns a string.
25-25: LGTM: Added return type annotation.The type annotation correctly specifies that this method returns a string.
29-29: LGTM: Added return type annotation.The type annotation correctly specifies that this method returns a list of strings.
33-33: LGTM: Added return type annotation.The type annotation correctly specifies that this method returns a list of strings.
37-37: LGTM: Added return type annotation.The type annotation correctly specifies that this method returns a list of RepositoryContributorNode objects.
backend/apps/github/management/commands/github_update_project_related_repositories.py (3)
15-15: LGTM: Added type annotation for logger.The type annotation correctly specifies that the logger is of type logging.Logger.
23-23: LGTM: Added return type annotation.The None return type is appropriate since this method doesn't return a value. This follows the pattern used in other command classes throughout the codebase.
32-32: LGTM: Added return type annotation.The None return type is appropriate since this method doesn't return a value. This follows the pattern used in other command classes throughout the codebase.
backend/apps/owasp/graphql/nodes/committee.py (6)
26-26: LGTM: Added return type annotation.The type annotation correctly specifies that this method returns a string.
30-30: LGTM: Added return type annotation.The type annotation correctly specifies that this method returns an integer.
34-34: LGTM: Added return type annotation.The type annotation correctly specifies that this method returns an integer.
38-38: LGTM: Added return type annotation.The type annotation correctly specifies that this method returns an integer.
42-42: LGTM: Added return type annotation.The type annotation correctly specifies that this method returns an integer. The fixed return value of 1 is correctly typed.
46-46: LGTM: Added return type annotation.The type annotation correctly specifies that this method returns an integer.
backend/apps/github/models/release.py (6)
47-47: LGTM: Added return type annotation.The str return type is appropriate for the str method, which should always return a string.
57-57: LGTM: Added return type annotation.The str return type is appropriate for this property that returns a formatted string representation of the release.
62-62: LGTM: Added return type annotation.The str return type is appropriate for this property that returns a URL string.
66-66: LGTM: Added return type annotation.The None return type is appropriate since this method updates the instance in-place and doesn't return a value.
99-99: LGTM: Added return type annotation.The None return type is appropriate since this method performs a bulk save operation and doesn't return a value.
104-104: LGTM: Added return type annotation and save parameter type.The return type "Release" correctly indicates that this method returns a Release instance. The addition of a keyword-only argument with type annotation (save: bool = True) is also a good practice and consistent with similar methods across the codebase.
backend/apps/github/models/issue.py (7)
3-4: Well-implemented type annotations preparation.Adding the
__future__import is crucial for enabling the use of forward references in type annotations, which allows for referencing types before they are defined.
79-79: Good return type annotation.Adding
-> Noneexplicitly indicates that this method mutates state but doesn't return a value, which improves code clarity and helps with static type checking.
116-116: Appropriate parameter and return type annotations.The type annotations for
open_aicorrectly use the union type operator to indicate it can be either anOpenAiinstance orNone. The integer type formax_tokensand return type ofNoneare also appropriate.
132-132: Consistent type annotations with generate_hint method.The type annotations here mirror those in the
generate_hintmethod, maintaining consistency across similar methods.
154-154: Clear return type annotation for save method.Adding
-> Noneexplicitly indicates that this method doesn't return a value, following Django's convention for save methods.
166-166: Consistent return type annotation for bulk_save.The
-> Nonereturn type is consistent with the implementation inBulkSaveModel.bulk_saveand clearly indicates the method doesn't return a value.
177-177: Good use of keyword-only parameter.Making
savea keyword-only parameter (using*,) is a good practice as it prevents positional argument errors and makes the function call more explicit. The boolean type annotation is also appropriate.backend/apps/owasp/models/committee.py (5)
30-30: Appropriate return type for str method.Adding
-> strcorrectly specifies that this method returns a string, which aligns with Python's expectation for the__str__magic method.
34-34: Consistent return type annotation.The
-> Nonereturn type is appropriate as this method modifies the instance but doesn't return a value, consistent with similar methods in related classes.
50-50: Clear return type for save method.Adding
-> Nonefollows Django's convention for save methods and is consistent with the annotation in other model classes.
69-69: Proper return type for bulk_save.The
-> Nonereturn type is consistent with similar implementations in other model classes.
74-74: Good use of forward reference and keyword-only parameter.Using
-> "Committee"as a forward reference is a good practice when returning the current class. Makingsavea keyword-only parameter is also appropriate and consistent with other update_data methods.backend/apps/common/utils.py (8)
3-4: Well-implemented type annotations setup.Adding the
__future__import enables the use of forward references in type annotations, which is a good practice for type hinting.
15-15: Clear parameter and return type annotations.The
path: strparameter type and-> strreturn type provide clear expectations for this utility function.
28-28: Appropriate return type annotation.The
-> strreturn type accurately reflects what this function returns.
38-38: Helpful return type annotation.The
-> strreturn type clarifies what consumers of this function can expect.
55-55: Well-structured type annotations.The parameter types
fields: list, delimiter: str = " "and return type-> strare clearly specified and match the function's implementation.
69-69: Good use of union type.Using
value: int | strcorrectly indicates that this function can accept either an integer or a string, which matches its implementation.
102-102: Appropriate parameter and return type annotations.The
text: strparameter type and-> strreturn type are clear and match the function's behavior.
115-115: Complete and clear type annotations.All parameters have appropriate type annotations, and the return type is clearly specified as a string.
backend/apps/owasp/models/event.py (8)
3-6: Well-structured type annotations setup.Adding both the
__future__import and explicitly importingdatefromdatetimeprepares the file for proper type hinting.
53-53: Appropriate return type for str method.The
-> strreturn type correctly matches the expected return type of the__str__magic method.
72-72: Thorough parameter and return type annotations.The parameter types
events: list, fields: list | None = Noneand return type-> Noneare well-specified and match the method's implementation.
87-87: Clear return type with union.Using
-> date | Nonecorrectly indicates that this method either returns a date object or None, which matches its implementation.
139-139: Good use of keyword-only parameter and return type.Making
savea keyword-only parameter is consistent with similar methods in other classes. The return type-> Eventclearly indicates what callers can expect.
163-163: Appropriate parameter and return type annotations.The parameter types
category: str, data: dictand return type-> Noneare clear and match the method's behavior.
192-192: Consistent return type annotations for generator methods.All these methods that generate data for the instance appropriately specify
-> Noneas their return type, indicating they modify the instance but don't return values.Also applies to: 208-208, 229-229
248-248: Well-implemented keyword-only parameter and return type.Making
include_datesa keyword-only parameter improves the clarity of function calls. The return type-> straccurately reflects what this method returns.backend/apps/owasp/models/chapter.py (8)
3-4: Good addition of type annotation support.Adding the
from __future__ import annotationsimport enables forward references in type annotations, which is particularly useful for self-referencing types and circular dependencies.
62-64: Well-typed string representation method.The return type annotation for
__str__correctly indicates that this method returns a string, following Python typing best practices.
77-102: Appropriate return type forfrom_githubmethod.The
-> Nonereturn type annotation is correct since this method updates the instance in-place without returning a value, consistent with similar methods in other classes likeRepositoryBasedEntityModel.
103-114: Correct return type forgenerate_geo_locationmethod.The
-> Nonereturn type annotation is appropriate for this method that sets instance attributes without returning a value.
115-134: Good parameter and return type annotations.The parameter type annotations for
OpenAi | Noneandintclearly communicate the expected parameter types, and the-> Nonereturn type is appropriate.
136-153: Well-structured parameter formatting and return type.The use of a keyword-only parameter with
*,notation forinclude_nameis a good practice for enforcing named parameter usage. The-> strreturn type correctly indicates the string return value.
155-169: Consistent return type annotation for Django model method.The
-> Nonereturn type for thesavemethod follows the Django convention and is consistent with similar methods in other models.
172-180: Well-typed static method with clear parameter types.The parameter type annotations for
chapters: listandfields: list | Noneprovide clear guidance on expected argument types, and the-> Nonereturn type is appropriate.backend/apps/owasp/models/project.py (7)
122-124: Correctly typed string representation method.The
-> strreturn type annotation for the__str__method accurately specifies its return type.
127-129: Appropriate boolean return types for property methods.The
-> boolreturn type annotations for theis_code_type,is_documentation_type, andis_tool_typeproperties correctly indicate that these methods return boolean values.Also applies to: 132-134, 137-139
151-153: Well-typed string properties.The
-> strreturn type annotations for thenest_keyandnest_urlproperties properly specify that these methods return string values.Also applies to: 156-158
180-183: Correct return type for action method.The
-> Nonereturn type annotation for thedeactivatemethod is appropriate as it modifies the instance in-place and doesn't return a value.
185-225: Appropriate return type for update method.The
-> Nonereturn type annotation for thefrom_githubmethod is correct as it updates the instance without returning a value.
226-237: Standard return type for Django model save method.The
-> Nonereturn type for thesavemethod follows Django conventions and is consistent with similar methods across the codebase.
257-279: Good use of keyword-only parameter and forward reference.The
*,notation for makingsavea keyword-only parameter is good practice, and the string literal-> "Project"as a forward reference for the return type is appropriate when returning an instance of the class being defined.backend/apps/common/index.py (12)
3-4: Good addition of type annotation support.Including
from __future__ import annotationsenables forward references in type annotations, necessary for self-referencing types and circular dependencies.
18-18: Properly typed logger variable.Explicitly typing the logger as
logging.Loggerimproves code clarity and enables better IDE support.
41-44: Correctly typed initializer method.The
-> Nonereturn type annotation for the__init__method is appropriate as initializers don't return values in Python.
47-51: Well-typed class method with correct return type.The
-> IndexRegistryreturn type annotation for theget_instanceclass method accurately specifies the return type.
53-63: Appropriate boolean return type.The
-> boolreturn type annotation for theis_indexablemethod correctly indicates its boolean return value.
65-83: Good method return type for method chaining.The
-> IndexRegistryreturn type annotation for theload_excluded_local_index_namesmethod correctly supports method chaining by returning self.
86-96: Properly typed standalone function.The
-> boolreturn type annotation for the standaloneis_indexablefunction correctly specifies its boolean return value.
125-142: Well-typed client factory method.The
-> SearchClientSyncreturn type annotation for theget_clientmethod clearly specifies the exact type being returned.
145-170: Correct return type for configuration method.The
-> Nonereturn type annotation for theconfigure_replicasmethod is appropriate as it performs configuration without returning a value.
173-216: Good use of union type for parsing method.The
-> list | Nonereturn type annotation for the_parse_synonyms_filemethod correctly indicates that it returns either a list or None.
219-247: Appropriate union return type for utility method.The
-> int | Nonereturn type annotation for thereindex_synonymsmethod properly indicates it returns either an integer count or None if an error occurs.
251-277: Accurate return type for count method.The
-> int | Nonereturn type annotation for theget_total_countmethod correctly specifies it returns either an integer count or None in case of errors.backend/apps/github/models/mixins/release.py (8)
3-4: Good addition of type annotation support.Adding
from __future__ import annotationsenables forward references and more complex type annotations.
12-14: Correct boolean return type for property.The
-> boolreturn type annotation for theis_indexableproperty properly indicates its boolean return value.
17-30: Well-structured complex return type.The
-> list[dict[str, str]]return type annotation provides clear information about the nested structure returned by theidx_authorproperty.
33-35: Numeric return type for timestamp property.The
-> floatreturn type annotation for theidx_created_atproperty correctly specifies the timestamp return format.
38-40: String return type for description property.The
-> strreturn type annotation for theidx_descriptionproperty accurately indicates its string return value.
43-45: Boolean return type for flag property.The
-> boolreturn type annotation for theidx_is_pre_releaseproperty correctly specifies its boolean return value.
48-50: Consistent string return types for index properties.The
-> strreturn type annotations for theidx_name,idx_project,idx_repository, andidx_tag_nameproperties properly indicate their string return values.Also applies to: 53-55, 63-65, 68-70
58-60: Appropriate union type for nullable timestamp.The
-> float | Nonereturn type annotation for theidx_published_atproperty correctly specifies that it returns either a float timestamp or None.backend/apps/common/management/commands/generate_sitemap.py (7)
31-31: Type annotation added correctlyThe return type annotation
-> Noneis correctly added to theadd_argumentsmethod, consistent with the pattern seen in other command files.
44-44: Type annotation added appropriatelyThe return type annotation
-> Nonefor thehandlemethod is appropriate as this method doesn't return any value, consistent with other command implementations.
73-73: Type annotations added correctlyThe parameter type annotation
output_dir: Pathand return type annotation-> Noneare correctly added to thegenerate_project_sitemapmethod.
94-94: Type annotations added correctlyThe parameter type annotation
output_dir: Pathand return type annotation-> Noneare correctly added to thegenerate_chapter_sitemapmethod.
115-115: Type annotations added correctlyThe parameter type annotation
output_dir: Pathand return type annotation-> Noneare correctly added to thegenerate_committee_sitemapmethod.
139-139: Type annotations added correctlyThe parameter type annotation
output_dir: Pathand return type annotation-> Noneare correctly added to thegenerate_user_sitemapmethod.
271-271: Type annotations added correctlyThe parameter type annotations
content: str, filepath: Pathand return type annotation-> Noneare correctly added to thesave_sitemapmethod.
| @@ -12,6 +12,6 @@ class PostQuery(BaseQuery): | |||
|
|
|||
| recent_posts = graphene.List(PostNode, limit=graphene.Int(default_value=5)) | |||
|
|
|||
| def resolve_recent_posts(root, info, limit=6): | |||
| def resolve_recent_posts(root, info, limit: int = 6) -> list: | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
The type annotations can be improved for better clarity and consistency.
While adding type annotations is a good step, there are several improvements that could be made:
- The return type should be more specific than just
list. Consider usingList[PostNode]fromtypingto clearly indicate what the list contains. - There's an inconsistency between the GraphQL field definition (default_value=5 on line 13) and the resolver method (default=6 on line 15).
- The docstring states "Return the 5 most recent posts" but the default is 6 in the implementation.
- The
rootandinfoparameters could also benefit from type annotations for completeness.
-def resolve_recent_posts(root, info, limit: int = 6) -> list:
+from typing import List, Any
+
+def resolve_recent_posts(root: Any, info: graphene.ResolveInfo, limit: int = 5) -> List[PostNode]:
"""Return the 5 most recent posts."""📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| def resolve_recent_posts(root, info, limit: int = 6) -> list: | |
| from typing import List, Any | |
| def resolve_recent_posts(root: Any, info: graphene.ResolveInfo, limit: int = 5) -> List[PostNode]: | |
| """Return the 5 most recent posts.""" |
| @@ -10,7 +11,7 @@ | |||
| COMMAND = "/sponsor" | |||
|
|
|||
|
|
|||
| def sponsor_handler(ack, command, client): | |||
| def sponsor_handler(ack, command: dict, client: WebClient) -> None: | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Type annotations added to sponsor_handler function.
The function now has appropriate type annotations for the command parameter (dict), the client parameter (WebClient), and the return type (None). However, the ack parameter is missing a type annotation.
-def sponsor_handler(ack, command: dict, client: WebClient) -> None:
+def sponsor_handler(ack: Callable[[], None], command: dict, client: WebClient) -> None:This would require adding an import for Callable from the typing module:
+from typing import Callable
from django.conf import settings
from slack_sdk import WebClient📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| def sponsor_handler(ack, command: dict, client: WebClient) -> None: | |
| from typing import Callable | |
| from django.conf import settings | |
| from slack_sdk import WebClient | |
| def sponsor_handler(ack: Callable[[], None], command: dict, client: WebClient) -> None: | |
| # function implementation goes here | |
| pass |
yashgoyal0110
force-pushed
the
feat/adding-type-annotations
branch
2 times, most recently
from
188fccd to
7bbfe60
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
backend/apps/slack/utils.py (1)
23-33: 🛠️ Refactor suggestionMissing type annotations for the escape function.
While type annotations have been added to all other functions in the file, the
escapefunction is missing them.-def escape(content): +def escape(content: str) -> str: """Escape HTML content. Args: content (str): The HTML content to escape. Returns: str: The escaped HTML content. """ return escape_html(content, quote=False)
🧹 Nitpick comments (5)
backend/apps/slack/utils.py (3)
37-37: Consider using a more specific return type.While adding the
inttype for parameter andlistfor return type is good, the return type could be more specific about what the list contains.-def get_gsoc_projects(year: int) -> list: +def get_gsoc_projects(year: int) -> list[dict]:
125-125: Consider using Optional type for clarity.While
None | listis technically correct, usingOptional[list]from the typing module might be more readable.- return None + return None # Optional[list] return type
183-183: Consider a more specific list type.While
listis correct, specifying what the list contains would provide more type information.-def get_text(blocks: list) -> str: +def get_text(blocks: list[dict]) -> str:backend/apps/owasp/models/mixins/project.py (2)
77-77: Consider a more specific dictionary type.While
list[dict]is correct, it could be more specific about the structure of the dictionaries.-def idx_repositories(self) -> list[dict]: +def idx_repositories(self) -> list[dict[str, str | int | bool]]:
105-105: Consider using a more specific list type.The return type could be more specific about what the list contains, based on the relevant code snippets from
repository.py.-def idx_top_contributors(self) -> list: +def idx_top_contributors(self) -> list[dict[str, Any]]:You'll also need to add
from typing import Anyto the imports.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
backend/poetry.lockis excluded by!**/*.lock
📒 Files selected for processing (112)
.pre-commit-config.yaml(1 hunks)backend/apps/common/geocoding.py(1 hunks)backend/apps/common/index.py(10 hunks)backend/apps/common/management/commands/algolia_update_replicas.py(1 hunks)backend/apps/common/management/commands/algolia_update_synonyms.py(1 hunks)backend/apps/common/management/commands/generate_sitemap.py(12 hunks)backend/apps/common/management/commands/load_data.py(1 hunks)backend/apps/common/management/commands/purge_data.py(1 hunks)backend/apps/common/models.py(1 hunks)backend/apps/common/open_ai.py(6 hunks)backend/apps/common/utils.py(8 hunks)backend/apps/core/api/algolia.py(3 hunks)backend/apps/core/models/prompt.py(12 hunks)backend/apps/core/utils/index.py(3 hunks)backend/apps/core/validators.py(6 hunks)backend/apps/github/admin.py(4 hunks)backend/apps/github/api/search/user.py(1 hunks)backend/apps/github/common.py(1 hunks)backend/apps/github/graphql/queries/issue.py(2 hunks)backend/apps/github/graphql/queries/pull_request.py(2 hunks)backend/apps/github/graphql/queries/release.py(2 hunks)backend/apps/github/graphql/queries/repository_contributor.py(1 hunks)backend/apps/github/index/release.py(2 hunks)backend/apps/github/index/repository.py(2 hunks)backend/apps/github/index/user.py(2 hunks)backend/apps/github/management/commands/github_enrich_issues.py(2 hunks)backend/apps/github/management/commands/github_update_owasp_organization.py(2 hunks)backend/apps/github/management/commands/github_update_project_related_repositories.py(2 hunks)backend/apps/github/models/common.py(1 hunks)backend/apps/github/models/generic_issue_model.py(1 hunks)backend/apps/github/models/issue.py(7 hunks)backend/apps/github/models/label.py(2 hunks)backend/apps/github/models/mixins/release.py(2 hunks)backend/apps/github/models/mixins/repository.py(3 hunks)backend/apps/github/models/organization.py(3 hunks)backend/apps/github/models/pull_request.py(2 hunks)backend/apps/github/models/release.py(3 hunks)backend/apps/github/models/repository.py(5 hunks)backend/apps/github/models/repository_contributor.py(3 hunks)backend/apps/github/models/user.py(3 hunks)backend/apps/github/utils.py(5 hunks)backend/apps/owasp/admin.py(1 hunks)backend/apps/owasp/api/search/chapter.py(1 hunks)backend/apps/owasp/api/search/committee.py(1 hunks)backend/apps/owasp/api/search/issue.py(1 hunks)backend/apps/owasp/api/search/project.py(1 hunks)backend/apps/owasp/graphql/nodes/chapter.py(1 hunks)backend/apps/owasp/graphql/nodes/committee.py(1 hunks)backend/apps/owasp/graphql/nodes/common.py(1 hunks)backend/apps/owasp/graphql/queries/post.py(1 hunks)backend/apps/owasp/graphql/queries/stats.py(1 hunks)backend/apps/owasp/index/project.py(1 hunks)backend/apps/owasp/management/commands/add_project_custom_tags.py(3 hunks)backend/apps/owasp/management/commands/owasp_aggregate_projects.py(2 hunks)backend/apps/owasp/management/commands/owasp_enrich_chapters.py(2 hunks)backend/apps/owasp/management/commands/owasp_enrich_committees.py(2 hunks)backend/apps/owasp/management/commands/owasp_enrich_events.py(2 hunks)backend/apps/owasp/management/commands/owasp_enrich_projects.py(2 hunks)backend/apps/owasp/management/commands/owasp_process_snapshots.py(3 hunks)backend/apps/owasp/management/commands/owasp_scrape_chapters.py(2 hunks)backend/apps/owasp/management/commands/owasp_scrape_committees.py(2 hunks)backend/apps/owasp/management/commands/owasp_scrape_projects.py(2 hunks)backend/apps/owasp/management/commands/owasp_sync_posts.py(3 hunks)backend/apps/owasp/management/commands/owasp_update_events.py(1 hunks)backend/apps/owasp/management/commands/owasp_update_project_health_requirements.py(2 hunks)backend/apps/owasp/management/commands/owasp_update_sponsors.py(1 hunks)backend/apps/owasp/models/chapter.py(9 hunks)backend/apps/owasp/models/committee.py(3 hunks)backend/apps/owasp/models/event.py(10 hunks)backend/apps/owasp/models/mixins/chapter.py(2 hunks)backend/apps/owasp/models/mixins/project.py(3 hunks)backend/apps/owasp/models/post.py(3 hunks)backend/apps/owasp/models/project.py(7 hunks)backend/apps/owasp/models/project_health_metrics.py(1 hunks)backend/apps/owasp/models/project_health_requirements.py(1 hunks)backend/apps/owasp/models/snapshot.py(1 hunks)backend/apps/owasp/models/sponsor.py(4 hunks)backend/apps/owasp/scraper.py(3 hunks)backend/apps/slack/actions/home.py(2 hunks)backend/apps/slack/apps.py(3 hunks)backend/apps/slack/blocks.py(4 hunks)backend/apps/slack/commands/board.py(2 hunks)backend/apps/slack/commands/chapters.py(2 hunks)backend/apps/slack/commands/committees.py(2 hunks)backend/apps/slack/commands/community.py(2 hunks)backend/apps/slack/commands/contact.py(2 hunks)backend/apps/slack/commands/contribute.py(2 hunks)backend/apps/slack/commands/donate.py(2 hunks)backend/apps/slack/commands/events.py(2 hunks)backend/apps/slack/commands/gsoc.py(2 hunks)backend/apps/slack/commands/jobs.py(2 hunks)backend/apps/slack/commands/leaders.py(2 hunks)backend/apps/slack/commands/news.py(2 hunks)backend/apps/slack/commands/owasp.py(2 hunks)backend/apps/slack/commands/policies.py(2 hunks)backend/apps/slack/commands/projects.py(2 hunks)backend/apps/slack/commands/sponsor.py(2 hunks)backend/apps/slack/commands/sponsors.py(2 hunks)backend/apps/slack/commands/staff.py(2 hunks)backend/apps/slack/commands/users.py(2 hunks)backend/apps/slack/common/handlers/chapters.py(1 hunks)backend/apps/slack/common/handlers/committees.py(1 hunks)backend/apps/slack/common/handlers/contribute.py(1 hunks)backend/apps/slack/common/handlers/projects.py(1 hunks)backend/apps/slack/events/app_home_opened.py(1 hunks)backend/apps/slack/events/member_joined_channel/catch_all.py(1 hunks)backend/apps/slack/events/member_joined_channel/contribute.py(2 hunks)backend/apps/slack/events/member_joined_channel/gsoc.py(2 hunks)backend/apps/slack/events/team_join.py(2 hunks)backend/apps/slack/models/event.py(3 hunks)backend/apps/slack/utils.py(10 hunks)backend/pyproject.toml(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (106)
- backend/apps/common/management/commands/algolia_update_synonyms.py
- backend/apps/owasp/index/project.py
- backend/apps/github/graphql/queries/repository_contributor.py
- backend/apps/owasp/models/project_health_metrics.py
- backend/apps/slack/commands/users.py
- backend/apps/owasp/models/project_health_requirements.py
- backend/apps/owasp/graphql/queries/post.py
- backend/apps/owasp/graphql/queries/stats.py
- backend/apps/common/management/commands/algolia_update_replicas.py
- backend/apps/slack/commands/sponsor.py
- backend/apps/github/models/generic_issue_model.py
- backend/apps/slack/commands/board.py
- backend/apps/common/management/commands/load_data.py
- backend/apps/owasp/management/commands/owasp_update_sponsors.py
- backend/apps/slack/events/member_joined_channel/catch_all.py
- backend/apps/slack/commands/donate.py
- backend/apps/slack/commands/staff.py
- backend/apps/slack/commands/contribute.py
- .pre-commit-config.yaml
- backend/apps/owasp/api/search/chapter.py
- backend/apps/slack/commands/chapters.py
- backend/apps/slack/actions/home.py
- backend/apps/slack/common/handlers/chapters.py
- backend/apps/common/management/commands/purge_data.py
- backend/apps/owasp/api/search/committee.py
- backend/apps/slack/commands/community.py
- backend/apps/github/index/release.py
- backend/apps/github/index/repository.py
- backend/apps/owasp/management/commands/owasp_enrich_committees.py
- backend/apps/slack/commands/sponsors.py
- backend/apps/slack/commands/owasp.py
- backend/apps/github/graphql/queries/release.py
- backend/apps/github/common.py
- backend/apps/owasp/api/search/issue.py
- backend/apps/owasp/admin.py
- backend/apps/slack/common/handlers/projects.py
- backend/apps/github/models/common.py
- backend/apps/slack/commands/committees.py
- backend/apps/github/api/search/user.py
- backend/apps/slack/common/handlers/committees.py
- backend/apps/github/index/user.py
- backend/apps/slack/events/app_home_opened.py
- backend/apps/slack/common/handlers/contribute.py
- backend/apps/slack/commands/contact.py
- backend/apps/owasp/api/search/project.py
- backend/apps/slack/commands/news.py
- backend/apps/owasp/management/commands/owasp_scrape_projects.py
- backend/apps/common/geocoding.py
- backend/apps/slack/commands/events.py
- backend/apps/common/models.py
- backend/apps/github/graphql/queries/pull_request.py
- backend/apps/github/models/label.py
- backend/apps/slack/commands/leaders.py
- backend/apps/slack/commands/projects.py
- backend/apps/github/models/user.py
- backend/apps/slack/commands/policies.py
- backend/apps/owasp/management/commands/owasp_enrich_projects.py
- backend/apps/owasp/management/commands/owasp_update_project_health_requirements.py
- backend/apps/slack/apps.py
- backend/apps/slack/commands/jobs.py
- backend/apps/github/management/commands/github_enrich_issues.py
- backend/apps/owasp/management/commands/owasp_process_snapshots.py
- backend/apps/owasp/management/commands/owasp_aggregate_projects.py
- backend/apps/github/models/organization.py
- backend/apps/owasp/graphql/nodes/chapter.py
- backend/apps/owasp/scraper.py
- backend/apps/core/api/algolia.py
- backend/apps/owasp/management/commands/owasp_sync_posts.py
- backend/apps/github/graphql/queries/issue.py
- backend/apps/github/utils.py
- backend/apps/github/admin.py
- backend/apps/owasp/management/commands/add_project_custom_tags.py
- backend/apps/github/models/repository_contributor.py
- backend/apps/owasp/management/commands/owasp_update_events.py
- backend/apps/owasp/management/commands/owasp_scrape_committees.py
- backend/apps/core/utils/index.py
- backend/apps/github/models/repository.py
- backend/apps/owasp/management/commands/owasp_enrich_events.py
- backend/apps/github/management/commands/github_update_owasp_organization.py
- backend/apps/slack/events/member_joined_channel/contribute.py
- backend/apps/common/open_ai.py
- backend/apps/owasp/models/snapshot.py
- backend/apps/github/models/pull_request.py
- backend/apps/github/models/release.py
- backend/apps/github/management/commands/github_update_project_related_repositories.py
- backend/apps/slack/blocks.py
- backend/apps/slack/commands/gsoc.py
- backend/apps/owasp/models/sponsor.py
- backend/apps/owasp/management/commands/owasp_scrape_chapters.py
- backend/apps/core/validators.py
- backend/apps/owasp/graphql/nodes/committee.py
- backend/apps/owasp/models/committee.py
- backend/apps/github/models/issue.py
- backend/apps/common/utils.py
- backend/apps/common/index.py
- backend/apps/owasp/management/commands/owasp_enrich_chapters.py
- backend/apps/owasp/models/chapter.py
- backend/apps/owasp/models/post.py
- backend/apps/owasp/models/event.py
- backend/apps/github/models/mixins/release.py
- backend/apps/common/management/commands/generate_sitemap.py
- backend/apps/owasp/models/project.py
- backend/apps/owasp/models/mixins/chapter.py
- backend/apps/owasp/graphql/nodes/common.py
- backend/apps/core/models/prompt.py
- backend/apps/github/models/mixins/repository.py
🧰 Additional context used
🧬 Code Definitions (4)
backend/apps/slack/models/event.py (6)
backend/apps/core/models/prompt.py (1)
save(29-39)backend/apps/github/models/pull_request.py (1)
save(92-94)backend/apps/github/models/issue.py (1)
save(154-163)backend/apps/owasp/models/chapter.py (1)
save(155-169)backend/apps/owasp/models/snapshot.py (1)
save(42-53)backend/apps/owasp/models/project.py (1)
save(228-239)
backend/apps/slack/events/member_joined_channel/gsoc.py (1)
backend/apps/slack/commands/gsoc.py (1)
gsoc_handler(21-93)
backend/apps/slack/utils.py (1)
backend/apps/core/models/prompt.py (1)
get_text(42-57)
backend/apps/owasp/models/mixins/project.py (7)
backend/apps/github/models/mixins/repository.py (7)
idx_contributors_count(31-33)idx_forks_count(46-48)idx_key(56-58)idx_languages(61-63)idx_name(71-73)idx_stars_count(96-98)idx_top_contributors(106-124)backend/apps/owasp/models/mixins/chapter.py (4)
idx_is_active(34-36)idx_key(39-41)idx_top_contributors(69-71)idx_updated_at(74-76)backend/apps/github/models/mixins/user.py (4)
idx_issues_count(142-144)idx_key(44-46)idx_name(69-71)idx_updated_at(173-175)backend/apps/owasp/models/project.py (1)
open_issues(163-169)backend/apps/owasp/models/mixins/committee.py (3)
idx_key(15-17)idx_top_contributors(25-27)idx_updated_at(30-32)backend/apps/github/models/mixins/release.py (1)
idx_name(48-50)backend/apps/owasp/models/mixins/common.py (1)
idx_name(23-25)
🔇 Additional comments (36)
backend/apps/slack/events/member_joined_channel/gsoc.py (3)
6-6: Good addition of WebClient import.The import of
WebClientfromslack_sdkproperly supports the type annotation on theclientparameter in thegsoc_handlerfunction.
16-16: LGTM: Clear logger type annotation.Type annotation for the logger variable improves code clarity and helps with static type checking.
19-19: Well-structured type annotations on the handler function.The type annotations on this function signature align well with the docstring descriptions. Parameter
eventis correctly typed asdict,clientasWebClient, and the return type is explicitly marked asNone.backend/apps/slack/events/team_join.py (3)
6-6: Good addition of WebClient import.The import of
WebClientfromslack_sdkproperly supports the type annotation on theclientparameter in theteam_join_handlerfunction.
32-32: LGTM: Clear logger type annotation.Type annotation for the logger variable improves code clarity and helps with static type checking.
35-35: Well-structured type annotations on the handler function.The type annotations on this function signature align well with the docstring descriptions. Parameter
eventis correctly typed asdict,clientasWebClient, and the return type is explicitly marked asNone.backend/apps/slack/models/event.py (2)
23-23: Proper return type annotation for string representation.Adding the
-> strreturn type to the__str__method is correct and aligns with the method's purpose.
32-32: LGTM: Adding return type annotation to from_slack method.The
-> Nonereturn type annotation accurately represents that this method doesn't return a value.backend/pyproject.toml (2)
97-117: Appropriate expansion of linting rule exceptions.The added ignore rules (
A002,ARG001,TC002,TC003,RUF013) are reasonably included to accommodate the codebase's style when adding type annotations.
142-154: Good mypy configuration for gradual typing.The added mypy configuration is well-structured for a project adopting type hints incrementally:
ignore_missing_imports = truesensibly prevents errors for third-party libraries without type stubs- Disabling specific error codes allows for a phased approach to type checking implementation
This configuration balances type safety with practicality during the transition to a fully typed codebase.
backend/apps/slack/utils.py (9)
3-4: Good addition of future annotations import.Adding
from __future__ import annotationsis necessary for forward references in type annotations and follows best practices for Python type hinting.
13-13: Appropriate import for type annotation.The QuerySet import is correctly added to support the return type annotations in multiple functions.
20-20: Properly typed logger variable.Adding a specific type annotation for the logger variable improves code clarity and IDE support.
62-64: Well-detailed type annotations for complex parameters.The comprehensive type annotation for the
timeoutparameter correctly captures all possible types that therequests.getfunction accepts. The return type is also properly specified.
100-102: Detailed type annotation for timeout parameter.The timeout parameter's complex type annotation correctly reflects all possible types that can be passed to the
requestsmodule.
128-128: Appropriate return type annotation.The return type annotation correctly specifies that this function returns either a QuerySet or None.
144-144: Correct parameter and return type annotations.Both the parameter and return type annotations are appropriately specified.
164-164: Consistent type annotations.The type annotations are consistent with similar functions in the file.
236-236: Appropriate string type annotations.The parameter and return type annotations correctly specify that both are strings.
backend/apps/owasp/models/mixins/project.py (17)
3-4: Good addition of future annotations import.Adding
from __future__ import annotationsis necessary to support forward references in type annotations.
17-17: Appropriate return type annotation.Adding a specific return type to the
idx_companiesproperty enhances code clarity.
22-22: Correct integer return type.The
intreturn type is appropriate for a count property.
27-27: Consistent string return type.The
strreturn type correctly matches what the property returns.
32-32: Appropriate integer return type.The
intreturn type is correct for the forks count property.
37-37: Proper boolean return type.The
boolreturn type is appropriate for the active status property.
42-42: Correct integer return type.The
intreturn type is appropriate for an issues count property.
47-47: Accurate string return type.The
strreturn type matches what the property returns.
52-52: Specific list type annotation.The
list[str]return type correctly specifies that the list contains strings.
57-57: Proper string return type.The
strreturn type is appropriate for the level text property.
62-62: Accurate union type for nullable float.The
float | Nonereturn type correctly handles the case where level_raw might be None.
67-67: Correct string return type.The
strreturn type is appropriate for the name property.
72-72: Proper string return type.The
strreturn type is consistent with what the property returns.
95-95: Appropriate integer return type.The
intreturn type is correct for a count property.
100-100: Correct integer return type.The
intreturn type is appropriate for the stars count property.
110-110: Proper string return type.The
strreturn type is appropriate for the type property.
115-115: Well-chosen union type.The
str | floatreturn type correctly handles both the timestamp and empty string cases.
yashgoyal0110
force-pushed
the
feat/adding-type-annotations
branch
from
222c4c3 to
2cf56d0
Compare
yashgoyal0110
force-pushed
the
feat/adding-type-annotations
branch
from
85d9a14 to
37d9a90
Compare
yashgoyal0110
force-pushed
the
feat/adding-type-annotations
branch
from
9d39cf2 to
266998b
Compare
|
@CodeRabbit |
|
Tip For best results, initiate chat on the files or code changes. @yashgoyal0110 I've reviewed your PR for adding type annotations, and overall it looks great! Here's my assessment: Strengths
Considerations
These type annotations will significantly improve code maintainability, IDE support, and help catch type-related bugs earlier in the development process. Type hints also serve as implicit documentation, making it easier for developers to understand function interfaces. Great job on making this improvement to the codebase!✏️ Learnings added
|
There was a problem hiding this comment.
These exceptions are to broad. Please revisit them and do your best to reduce them if possible.
backend/pyproject.toml
Outdated
|
|
||
|
|
||
| [build-system] | ||
| build-backend = "poetry.core.masonry.api" | ||
| requires = ["poetry-core"] | ||
|
|
||
| [tool.mypy] |
There was a problem hiding this comment.
Please order it properly.
.pre-commit-config.yaml
Outdated
| @@ -26,6 +26,17 @@ repos: | |||
| types: | |||
| - html | |||
|
|
|||
| - repo: https://github.com/pre-commit/mirrors-mypy | |||
There was a problem hiding this comment.
Please sort it alphabetically.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
backend/apps/github/graphql/queries/repository_contributor.py (1)
21-22: Fix PEP 8 style issues.There are two PEP 8 style issues to address:
- Line 21 contains whitespace on a blank line
- Line 22 exceeds the maximum line length of 99 characters
- - def resolve_top_contributors(root, info, limit: int, organization=None) -> list[RepositoryContributorNode]: + + def resolve_top_contributors( + root, info, limit: int, organization=None + ) -> list[RepositoryContributorNode]:🧰 Tools
🪛 Ruff (0.8.2)
21-21: Blank line contains whitespace
Remove whitespace from blank line
(W293)
22-22: Line too long (111 > 99)
(E501)
backend/apps/github/graphql/queries/pull_request.py (1)
24-26: Fix line length and improve parameter type annotations.The parameter line exceeds the maximum length of 99 characters. Additionally, consider typing the
organizationparameter for completeness.def resolve_recent_pull_requests( - root, info, limit: int, *, distinct: bool = False, login: str | None = None, organization=None + root, info, limit: int, *, distinct: bool = False, login: str | None = None, + organization: str | None = None ) -> QuerySet:🧰 Tools
🪛 Ruff (0.8.2)
25-25: Line too long (102 > 99)
(E501)
backend/apps/github/graphql/queries/issue.py (1)
24-26: Fix line length and improve parameter type annotations.The parameter line exceeds the maximum length of 99 characters. Additionally, consider typing the
organizationparameter for completeness.def resolve_recent_issues( - root, info, limit: int, *, distinct: bool = False, login: str | None = None, organization=None + root, info, limit: int, *, distinct: bool = False, login: str | None = None, + organization: str | None = None ) -> QuerySet:🧰 Tools
🪛 Ruff (0.8.2)
25-25: Line too long (102 > 99)
(E501)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
backend/poetry.lockis excluded by!**/*.lock
📒 Files selected for processing (9)
.pre-commit-config.yaml(1 hunks)backend/apps/common/management/commands/generate_sitemap.py(12 hunks)backend/apps/core/utils/index.py(3 hunks)backend/apps/github/graphql/queries/issue.py(2 hunks)backend/apps/github/graphql/queries/pull_request.py(2 hunks)backend/apps/github/graphql/queries/release.py(2 hunks)backend/apps/github/graphql/queries/repository_contributor.py(1 hunks)backend/apps/owasp/models/event.py(12 hunks)backend/apps/slack/commands/community.py(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (6)
- backend/apps/slack/commands/community.py
- backend/apps/github/graphql/queries/release.py
- .pre-commit-config.yaml
- backend/apps/core/utils/index.py
- backend/apps/owasp/models/event.py
- backend/apps/common/management/commands/generate_sitemap.py
🧰 Additional context used
🧬 Code Graph Analysis (1)
backend/apps/github/graphql/queries/repository_contributor.py (1)
backend/apps/github/graphql/nodes/repository_contributor.py (1)
RepositoryContributorNode(6-14)
🪛 Ruff (0.8.2)
backend/apps/github/graphql/queries/issue.py
25-25: Line too long (102 > 99)
(E501)
backend/apps/github/graphql/queries/pull_request.py
25-25: Line too long (102 > 99)
(E501)
backend/apps/github/graphql/queries/repository_contributor.py
21-21: Blank line contains whitespace
Remove whitespace from blank line
(W293)
22-22: Line too long (111 > 99)
(E501)
🔇 Additional comments (7)
backend/apps/github/graphql/queries/repository_contributor.py (1)
22-22: Type annotations properly reflect implementation.The added type annotations correctly specify
limitas an integer and the return type as a list ofRepositoryContributorNodeobjects, which matches the actual implementation in lines 81-91. These type hints will improve code maintainability and IDE support.🧰 Tools
🪛 Ruff (0.8.2)
22-22: Line too long (111 > 99)
(E501)
backend/apps/github/graphql/queries/pull_request.py (3)
3-4: Good use of future annotations import.Adding
from __future__ import annotationsis appropriate for using the newer Python type hinting syntax, particularly for the Union type with the|operator.
6-6: Properly added QuerySet import.Adding
QuerySetto the imports is consistent with the updated return type annotation on theresolve_recent_pull_requestsmethod.
24-26: Good practice using keyword-only parameters.Using the
*to make parameters keyword-only is a good practice for API stability, especially since these parameters have default values. This helps prevent positional argument errors when the function is called.🧰 Tools
🪛 Ruff (0.8.2)
25-25: Line too long (102 > 99)
(E501)
backend/apps/github/graphql/queries/issue.py (3)
3-4: Good use of future annotations import.Adding
from __future__ import annotationsis appropriate for using the newer Python type hinting syntax, particularly for the Union type with the|operator.
6-6: Properly added QuerySet import.Adding
QuerySetto the imports is consistent with the updated return type annotation on theresolve_recent_issuesmethod.
24-26: Consistent type annotations with pull_request.py.The type annotations are consistent with those added to
pull_request.py, which is good practice for maintaining a uniform codebase style. The use of keyword-only parameters (*) and Union types with the pipe operator (|) follows modern Python type hinting practices.🧰 Tools
🪛 Ruff (0.8.2)
25-25: Line too long (102 > 99)
(E501)
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
backend/apps/slack/common/gsoc.py (1)
39-70:⚠️ Potential issueData structure change: tuple to list inconsistent with PR objectives
The change from a tuple to a list for
GSOC_2025_MILESTONESrepresents a functional modification rather than just a type annotation. This change transforms the data structure from immutable (tuple) to mutable (list), which could potentially lead to unexpected behavior if any part of the codebase assumes this constant remains unchanged.According to the PR objectives, this pull request was intended to add type annotations without altering functionality. Consider either:
- Reverting back to a tuple to maintain immutability
- Adding a type annotation while keeping it as a list:
GSOC_2025_MILESTONES: list = [...]-GSOC_2025_MILESTONES = [ +GSOC_2025_MILESTONES: tuple = ( # content remains the same -] +)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (48)
.pre-commit-config.yaml(1 hunks)backend/apps/common/index.py(10 hunks)backend/apps/common/management/commands/generate_sitemap.py(14 hunks)backend/apps/common/utils.py(9 hunks)backend/apps/core/validators.py(7 hunks)backend/apps/github/management/commands/github_update_owasp_organization.py(3 hunks)backend/apps/github/migrations/0001_initial.py(6 hunks)backend/apps/github/models/issue.py(7 hunks)backend/apps/github/models/label.py(2 hunks)backend/apps/github/models/mixins/repository.py(3 hunks)backend/apps/github/models/organization.py(3 hunks)backend/apps/github/models/pull_request.py(2 hunks)backend/apps/github/models/release.py(3 hunks)backend/apps/github/models/repository_contributor.py(3 hunks)backend/apps/github/utils.py(5 hunks)backend/apps/owasp/graphql/nodes/common.py(2 hunks)backend/apps/owasp/index/project.py(1 hunks)backend/apps/owasp/management/commands/owasp_scrape_projects.py(3 hunks)backend/apps/owasp/management/commands/owasp_sync_posts.py(4 hunks)backend/apps/owasp/migrations/0016_remove_event_created_at_and_more.py(1 hunks)backend/apps/owasp/models/chapter.py(9 hunks)backend/apps/owasp/models/committee.py(3 hunks)backend/apps/owasp/models/event.py(12 hunks)backend/apps/owasp/models/mixins/chapter.py(2 hunks)backend/apps/owasp/models/mixins/committee.py(1 hunks)backend/apps/owasp/models/mixins/project.py(3 hunks)backend/apps/owasp/models/post.py(5 hunks)backend/apps/owasp/models/project.py(7 hunks)backend/apps/owasp/models/sponsor.py(3 hunks)backend/apps/slack/__init__.py(1 hunks)backend/apps/slack/commands/events.py(3 hunks)backend/apps/slack/commands/policies.py(3 hunks)backend/apps/slack/common/gsoc.py(2 hunks)backend/apps/slack/utils.py(10 hunks)backend/pyproject.toml(1 hunks)backend/tests/apps/common/utils_test.py(2 hunks)backend/tests/apps/github/models/label_test.py(1 hunks)backend/tests/apps/github/models/mixins/issue_test.py(3 hunks)backend/tests/apps/github/models/mixins/release_test.py(3 hunks)backend/tests/apps/github/models/mixins/repository_test.py(3 hunks)backend/tests/apps/github/models/mixins/user_test.py(6 hunks)backend/tests/apps/github/models/release_test.py(1 hunks)backend/tests/apps/owasp/models/post_test.py(5 hunks)backend/tests/apps/slack/commands/news_test.py(1 hunks)backend/tests/apps/slack/commands/projects_test.py(2 hunks)frontend/__tests__/e2e/pages/Home.spec.ts(1 hunks)frontend/__tests__/e2e/pages/footerIcons.spec.ts(0 hunks)frontend/src/components/MultiSearch.tsx(1 hunks)
💤 Files with no reviewable changes (1)
- frontend/tests/e2e/pages/footerIcons.spec.ts
✅ Files skipped from review due to trivial changes (5)
- backend/tests/apps/github/models/mixins/user_test.py
- backend/tests/apps/github/models/mixins/release_test.py
- backend/apps/slack/init.py
- backend/tests/apps/github/models/mixins/repository_test.py
- backend/tests/apps/github/models/mixins/issue_test.py
🚧 Files skipped from review as they are similar to previous changes (30)
- backend/apps/slack/commands/policies.py
- .pre-commit-config.yaml
- backend/apps/slack/commands/events.py
- backend/apps/github/management/commands/github_update_owasp_organization.py
- backend/apps/github/models/repository_contributor.py
- backend/apps/github/utils.py
- backend/apps/owasp/index/project.py
- backend/apps/github/models/organization.py
- backend/apps/owasp/management/commands/owasp_sync_posts.py
- backend/apps/github/models/label.py
- backend/apps/github/models/release.py
- backend/apps/owasp/management/commands/owasp_scrape_projects.py
- backend/apps/owasp/models/post.py
- backend/pyproject.toml
- backend/apps/github/models/pull_request.py
- backend/apps/core/validators.py
- backend/apps/owasp/graphql/nodes/common.py
- backend/apps/owasp/models/committee.py
- backend/apps/owasp/models/sponsor.py
- backend/apps/owasp/models/chapter.py
- backend/apps/common/index.py
- backend/apps/slack/utils.py
- backend/apps/github/models/issue.py
- backend/apps/common/utils.py
- backend/apps/owasp/models/event.py
- backend/apps/owasp/models/project.py
- backend/apps/owasp/models/mixins/chapter.py
- backend/apps/common/management/commands/generate_sitemap.py
- backend/apps/owasp/models/mixins/project.py
- backend/apps/github/models/mixins/repository.py
🧰 Additional context used
🧬 Code Graph Analysis (3)
backend/apps/owasp/models/mixins/committee.py (1)
backend/apps/owasp/models/common.py (1)
get_top_contributors(198-216)
backend/tests/apps/github/models/label_test.py (1)
backend/apps/github/models/label.py (1)
Label(9-80)
backend/tests/apps/github/models/release_test.py (1)
backend/apps/github/models/release.py (1)
Release(10-127)
🔇 Additional comments (22)
backend/tests/apps/common/utils_test.py (1)
1-1: Good modernization of timezone usage.You've updated the code to use
UTCdirectly from thedatetimemodule instead oftimezone.utc. This is a cleaner approach available in Python 3.11+ and maintains the same functionality while simplifying the imports and usage.This change aligns with modern Python practices and improves code readability without altering the test behavior.
Also applies to: 42-43
backend/tests/apps/github/models/label_test.py (1)
11-11: Updated assertion properly reflects the type-annotated method signatureThe assertion has been correctly updated to include the
fields=Noneparameter, which aligns with the updated method signature in theLabel.bulk_savemethod that now includes a-> Nonereturn type annotation and an optionalfieldsparameter.backend/tests/apps/github/models/release_test.py (1)
11-11: Updated assertion correctly reflects the type-annotated method signatureThe assertion has been appropriately updated to include the
fields=Noneparameter, which aligns with the updatedRelease.bulk_savemethod signature that now includes a-> Nonereturn type annotation and an optionalfieldsparameter.frontend/src/components/MultiSearch.tsx (1)
287-287: LGTM! Code simplification looks good.The change from a conditional expression to using the logical OR operator (
||) makes the code more concise while maintaining the same functionality. This is a common JavaScript/TypeScript pattern for fallback values.frontend/__tests__/e2e/pages/Home.spec.ts (3)
95-99: Good addition of test for the Bluesky icon.This test properly verifies both the visibility of the Bluesky icon and confirms it has the
target="_blank"attribute to ensure it opens in a new tab.
101-105: Good addition of test for the GitHub icon.This test properly verifies both the visibility of the GitHub icon and confirms it has the
target="_blank"attribute to ensure it opens in a new tab.
107-111: Good addition of test for the Slack icon.This test properly verifies both the visibility of the Slack icon and confirms it has the
target="_blank"attribute to ensure it opens in a new tab.backend/tests/apps/slack/commands/news_test.py (1)
55-57: The addition ofstrict=Falseis a good defensive programming practice.This change makes the
zip()function more resilient by ensuring it won't raise aValueErrorif the iterables have different lengths. While the current test logic should always have matching lengths (sincenews_blocksis sliced based onlen(mock_get_news_data.return_value)), this change safeguards against potential future modifications to the test.Note that this parameter was introduced in Python 3.10, and the change ensures compatibility with that version's stricter default behavior where
zip()would otherwise raise an exception for different length iterables.backend/tests/apps/slack/commands/projects_test.py (1)
1-1: Modernized datetime import and usage.The change from
timezone.utcto directly importing and usingUTCfrom the datetime module is a good modernization. This approach is cleaner and more direct, introduced in Python 3.11 as the recommended way to specify UTC timezone.Note that while this change improves code quality, it's not directly related to adding type annotations (the PR's stated purpose), but rather a code modernization improvement.
Also applies to: 64-64
backend/apps/owasp/migrations/0016_remove_event_created_at_and_more.py (1)
74-74: Good modernization of datetime timezone usage.The change from
datetime.timezone.utctodatetime.UTCis a good improvement.datetime.UTCwas introduced in Python 3.11 as a more concise way to reference UTC timezone compared todatetime.timezone.utc. This change is consistent with the type annotation improvements across the codebase and follows modern Python practices.backend/apps/github/migrations/0001_initial.py (6)
143-144: Consistent modernization of datetime timezone usage.Good update from
datetime.timezone.utctodatetime.UTC. This change uses Python 3.11's timezone constant, which is more concise and type-friendly than the older approach.
152-153: Consistent modernization of datetime timezone usage.The updated timezone approach is correctly applied here with
datetime.UTC.
358-359: Consistent modernization of datetime timezone usage.The migration of timezone representation to
datetime.UTCis correctly applied here.
367-368: Consistent modernization of datetime timezone usage.Good continuation of the timezone standardization pattern.
386-387: Consistent modernization of datetime timezone usage.Correctly applied the
datetime.UTCstandard here as well.
395-396: Consistent modernization of datetime timezone usage.The timezone update pattern is consistently applied throughout all datetime fields in this migration.
backend/tests/apps/owasp/models/post_test.py (5)
1-1: Good addition of UTC importImporting UTC directly from datetime module is cleaner than using timezone.utc, and follows current best practices for timezone handling in Python.
22-22: Properly updated timezone handlingChanged from timezone.utc to UTC for consistency with the new approach to timezone handling throughout the codebase.
41-41: Consistent timezone implementation in test dataGood job updating both instances of published_at in the test parameterization to use UTC instead of timezone.utc.
Also applies to: 48-48
57-57: Properly updated second test caseConsistent application of the UTC timezone standard in the second parameterized test case.
Also applies to: 64-64
87-87: Complete timezone handling updateFinal instance of timezone.utc correctly replaced with UTC in the test_update_data_existing_post method.
backend/apps/owasp/models/mixins/committee.py (1)
25-27:❓ Verification inconclusive
Verify behavior change:
super()toselfmethod call.The implementation has been changed from calling
super().get_top_contributorstoself.get_top_contributors. This changes the method resolution order and may affect behavior depending on your class hierarchy.Ensure this was an intentional change and not an accidental modification while adding type annotations. If the change was unintentional, revert to using
super().
🏁 Script executed:
#!/bin/bash # Check if there are any overrides of get_top_contributors in subclasses echo "Checking for potential method overrides in the inheritance chain:" rg -A 3 -B 3 "def get_top_contributors" --type py backend/apps/ # Check the CommitteeIndexMixin class hierarchy echo "\nChecking the class hierarchy for CommitteeIndexMixin:" rg -A 5 -B 5 "class.*\(.*CommitteeIndexMixin.*\)" --type py backend/apps/Length of output: 796
Action Required: Confirm Intended Method Resolution in Inheritance Chain
It appears that the change from calling
super().get_top_contributorstoself.get_top_contributorswas made in theidx_top_contributorsmethod. Our initial search shows thatget_top_contributorsis defined inbackend/apps/owasp/models/common.pywith no obvious overriding of this method in nearby subclasses. However, the automated search for theCommitteeIndexMixinhierarchy did not yield additional context, so the potential impact on method resolution (especially if any subclass later overridesget_top_contributors) remains unclear.Please verify that this modification is intentional. Confirm that invoking the method on
self(and thereby potentially using any subclass override) is the desired behavior compared to relying directly on the base class implementation viasuper(). If this change is not intended, revert to usingsuper().
| def idx_top_contributors(self): | ||
| """Return top contributors for indexing.""" | ||
| return super().get_top_contributors(repositories=[self.owasp_repository]) | ||
| return self.get_top_contributors(repositories=[self.owasp_repository]) |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Return type annotation is missing per PR objectives.
According to the PR objectives, this PR is adding type annotations across the codebase. However, while the method implementation has been updated to use self.get_top_contributors instead of super().get_top_contributors (as mentioned in the AI summary), the return type annotation (-> list) is missing from the method signature.
Add the return type annotation to align with the objectives of this PR:
@property
- def idx_top_contributors(self):
+ def idx_top_contributors(self) -> list:
"""Return top contributors for indexing."""
return self.get_top_contributors(repositories=[self.owasp_repository])📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| def idx_top_contributors(self): | |
| """Return top contributors for indexing.""" | |
| return super().get_top_contributors(repositories=[self.owasp_repository]) | |
| return self.get_top_contributors(repositories=[self.owasp_repository]) | |
| @property | |
| def idx_top_contributors(self) -> list: | |
| """Return top contributors for indexing.""" | |
| return self.get_top_contributors(repositories=[self.owasp_repository]) |
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
backend/pyproject.toml (1)
90-93: Mypy configuration settings for enhanced type checkingThe addition of the
[tool.mypy]section withexplicit_package_bases = true,ignore_missing_imports = true, andmypy_path = "backend"is a positive step toward comprehensive type checking. However, note that usingignore_missing_imports = truemay be too broad and could hide potential issues with missing type stubs. As previously noted in earlier reviews, consider revisiting this setting in the future for more granular suppression if feasible.
🧹 Nitpick comments (2)
backend/pyproject.toml (2)
95-98: Mypy override for 'attr-defined' errorsThe override disabling the
attr-definederror in the specified modules appears reasonable, especially when dealing with dynamic attributes or libraries that use attrs. To improve clarity for future maintainers, consider adding an inline comment explaining why this specific error code is disabled for these modules.
99-102: Mypy override for 'var-annotated' errors in migrationsDisabling the
var-annotatederror for migration files is a common workaround given that migrations often do not adhere strictly to type annotation requirements. As a suggestion for improved maintainability, it would be beneficial to include a brief comment outlining the rationale behind this suppression.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
backend/apps/owasp/models/mixins/committee.py(1 hunks)backend/pyproject.toml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- backend/apps/owasp/models/mixins/committee.py
🔇 Additional comments (1)
backend/pyproject.toml (1)
105-106: Ruff target version updateThe
target-versionis now set to"py313", which should help ensure linting consistency with Python 3.13 features. Please verify that all development and CI environments are prepared for Python 3.13 to avoid any compatibility issues.
|
fixes: #1258