[Integration][Gitlab] Added support for gitlab member ingestion #767

mk-armah · 2024-07-03T12:10:22Z

Description

Added support for GitLab member ingestion.

This PR introduces two new kinds: PROJECTWITHMEMBERS and GROUPWITHMEMBERS. These are enhanced versions of the original PROJECT and GROUP kinds, now including member data.

Public Email Visibility:
- GitLab group and project members do not include users' emails by default, especially for free plans. To enable users on free plans to view user emails, we have added a flag includePublicEmail to the member selector.
- Usage: If set to true, members are enriched with the public_email field from the /users endpoint. This is dependent on whether the user has allowed public email visibility in their GitLab account settings. Learn more.
- Note: It was necessary to call the /users endpoint because the members API does not include public_email.
- Default Value: The default value for includePublicEmail is false.
Bot Members Filtering:
- GitLab returns all members, including bots and tokens created as members. To filter out bots from actual members, we have added a flag includeBotMembers to the MemberSelector.
- Usage: If set to false, bot members are excluded from the synchronization process.
- Default Value: The default value for includeBotMembers is true, meaning bots are included by default.
- Reasoning: Bot filtering is necessary when syncing members to ensure only actual user accounts are considered.
Inherited Members Inclusion:
- GitLab allows inclusion of inherited members from parent groups. To control this behavior, we have added a flag includeInheritedMembers.
- Usage: If set to true, members inherited from parent groups are included during synchronization.
- Default Value: The default value for includeInheritedMembers is false, so inherited members are excluded by default.
- Note: Including inherited members can provide a more comprehensive view of all members who have access to a project or group through group hierarchies.

Type of change

Please leave one option from the following and delete the rest:

New feature (non-breaking change which adds functionality)

Screenshots

Tankilevitch · 2024-07-07T18:38:46Z

integrations/gitlab/.port/resources/blueprints.json

+        "publicEmail": {
+          "type": "string",
+          "title": "Public Email",
+          "description": "User's GitLab public email.",
+          "icon": "User",
+          "format": "user"


in what case the user will have a public email? I think we might want to remove it by default

Tankilevitch · 2024-07-07T18:39:50Z

integrations/gitlab/.port/resources/port-app-config.yaml

+          relations:
+            gitlabGroup: '[.__groups[].full_path]'
+            createdBy: .created_by.username


in the blueprint relation you only have gitlabGroup, while in your mapping you have both createdBy and gitlabGroup. I am not sure it is of interest for users who created the user, lets remove it. Let me know if you think otherwise

Tankilevitch · 2024-07-07T18:42:49Z

integrations/gitlab/gitlab_integration/gitlab_service.py

+        async def check_group_membership(group: Group) -> Group | None:
+            "check if the user is a member of the group"
+            async with semaphore:
+                try:
+                    await AsyncFetcher.fetch_single(group.members.get, member.get_id())
+                    return group
+                except GitlabError as err:
+                    if err.response_code != 404:
+                        raise err
+                    return None


this feels very insufficient, eventually for all the if I have 1 member, and 1000 groups, I'll have to query this api 1000 times to find out what groups he related to? isn't there any other way to get that data?

Tankilevitch · 2024-07-07T18:45:15Z

integrations/gitlab/gitlab_integration/gitlab_service.py

+        user_groups: List[dict[str, Any]] = [
+            {"id": group.id, "full_path": group.full_path}
+            async for groups in self.get_member_groups(user)
+            for group in groups
+        ]


I am not sure this should be the default behavior when quering members.

maybe this should be something that is part of group members kind? that will query the list of members of each group.
and instead of having a relation of user -> groups, we will have relation between group -> users

Tankilevitch · 2024-07-08T07:13:33Z

integrations/gitlab/gitlab_integration/gitlab_service.py

+    async def get_all_group_members(
+        self, group: Group
+    ) -> typing.AsyncIterator[List[GroupMemberAll]]:
+
+        logger.info(f"Fetching all members of group {group.name}")
+
+        async for users_batch in AsyncFetcher.fetch_batch(
+            fetch_func=group.members_all.list,
+            validation_func=self.should_run_for_member,
+            pagination="offset",
+            order_by="id",
+            sort="asc",
+        ):
+            members: List[GroupMemberAll] = typing.cast(
+                List[GroupMemberAll], users_batch
+            )
+            logger.info(
+                f"Queried {len(members)} members {[user.username for user in members]} from {group.name}"
+            )
+            yield members
+


Suggested change

async def get_all_group_members(

self, group: Group

) -> typing.AsyncIterator[List[GroupMemberAll]]:

logger.info(f"Fetching all members of group {group.name}")

async for users_batch in AsyncFetcher.fetch_batch(

fetch_func=group.members_all.list,

validation_func=self.should_run_for_member,

pagination="offset",

order_by="id",

sort="asc",

):

members: List[GroupMemberAll] = typing.cast(

List[GroupMemberAll], users_batch

)

logger.info(

f"Queried {len(members)} members {[user.username for user in members]} from {group.name}"

)

yield members

async def get_all_group_members(

self, group: Group

) -> typing.AsyncIterator[List[GroupMemberAll]]:

logger.info(f"Fetching all members of group {group.name}")

async for users_batch in AsyncFetcher.fetch_batch(

fetch_func=group.members_all.list,

validation_func=self.should_run_for_member,

pagination="offset",

order_by="id",

sort="asc",

):

members: List[GroupMemberAll] = typing.cast(

List[GroupMemberAll], users_batch

)

logger.info(

f"Queried {len(members)} members {[user.username for user in members]} from {group.name}"

)

members_enriched_with_group = [ {...member, group: group} for member in members ]

yield members

Tankilevitch · 2024-07-08T07:16:32Z

integrations/gitlab/gitlab_integration/gitlab_service.py

+    async def enrich_member_with_groups_and_public_email(
+        self, member
+    ) -> dict[str, Any]:
+        user: User = await self.get_user(member.id)


feature flag in the selector mapping, and defined in docs.

Tankilevitch · 2024-07-08T07:22:53Z

integrations/gitlab/gitlab_integration/ocean.py

+@ocean.on_resync(ObjectKind.MEMBER)
+async def resync_members(kind: str) -> ASYNC_GENERATOR_RESYNC_TYPE:
+    for service in get_cached_all_services():
+        for group in service.get_root_groups():
+            async for members_batch in service.get_all_group_members(group):
+                tasks = [
+                    service.enrich_member_with_groups_and_public_email(member)
+                    for member in members_batch
+                ]
+                members = await asyncio.gather(*tasks)
+                yield members


Suggested change

@ocean.on_resync(ObjectKind.MEMBER)

async def resync_members(kind: str) -> ASYNC_GENERATOR_RESYNC_TYPE:

for service in get_cached_all_services():

for group in service.get_root_groups():

async for members_batch in service.get_all_group_members(group):

tasks = [

service.enrich_member_with_groups_and_public_email(member)

for member in members_batch

]

members = await asyncio.gather(*tasks)

yield members

@ocean.on_resync(ObjectKind.GROUP_MEMBERS)

async def resync_members(kind: str) -> ASYNC_GENERATOR_RESYNC_TYPE:

for service in get_cached_all_services():

for group in service.get_root_groups():

group_members = []

async for members_batch in service.get_all_group_members(group):

group_memebers.append(members_batch)

yield { group: group, group_members: group_members }

stream_async_iterators_tasks

Tankilevitch · 2024-07-08T07:30:19Z

integrations/gitlab/.port/resources/blueprints.json

+      "gitlabGroup": {
+        "title": "Group",
+        "target": "gitlabGroup",
+        "required": false,
+        "many": true
+      }


missing group

Tankilevitch · 2024-07-25T17:38:01Z

integrations/gitlab/.port/resources/blueprints.json

+        "locked": {
+          "type": "string",
+          "title": "Locked",
+          "icon": "GitLab",
+          "description": "Indicates if the GitLab item is locked."
+        },


how is this locked?

Tankilevitch · 2024-07-25T17:38:36Z

integrations/gitlab/.port/resources/blueprints.json

+      "properties": {
+        "state": {
+          "title": "State",
+          "type": "string",
+          "icon": "GitLab",
+          "description": "The current state of the GitLab item (e.g., open, closed)."
+        },


we are talking about member not gitlab item, please make sure its readable and straight forward for the users

Tankilevitch · 2024-07-25T17:39:00Z

integrations/gitlab/.port/resources/blueprints.json

+        "visibility": {
+          "icon": "Lock",
+          "title": "Visibility",
+          "type": "string",
+          "enum": [
+            "public",
+            "internal",
+            "private"
+          ],
+          "enumColors": {
+            "public": "red",
+            "internal": "yellow",
+            "private": "green"
+          }


add description

Tankilevitch · 2024-07-25T17:39:52Z

integrations/gitlab/.port/resources/port-app-config.yaml

+            publicEmail: .__public_email
+          relations:
+            gitlabGroup: '[.__groups[].full_path]'
+            createdBy: .created_by.username


what is createdBy we don't have that kind of relation please remove

integrations/gitlab/gitlab_integration/ocean.py

Tankilevitch · 2024-07-25T17:53:22Z

integrations/gitlab/.port/resources/port-app-config.yaml

+            locked: .locked
+            link: .web_url
+            email: .email
+            publicEmail: .__public_email


lets remove by default

Tankilevitch · 2024-07-25T17:54:33Z

integrations/gitlab/.port/resources/blueprints.json

+    "relations": {
+      "members": {
+        "title": "Members",
+        "target": "member",
+        "required": false,
+        "many": true
+      }


shouldn't be here

relationship is group -> member

integrations/gitlab/.port/resources/blueprints.json

Tankilevitch · 2024-07-25T17:56:29Z

integrations/gitlab/gitlab_integration/gitlab_service.py

+    User,
+    GroupMember,


both, depends on the context

…improvement/gitlab

… defaulting to false

Tankilevitch · 2024-07-27T11:28:17Z

integrations/gitlab/gitlab_integration/git_integration.py

+    class MembersSelector(Selector):
+        public_email_visibility: bool | None = Field(
+            alias="publicEmailVisibility",
+            default=False,
+            description="If set to true, the integration will enrich members with public email field. Default value is false",
+        )
+


initialize the class outside of GitlabMembersResourceConfig that way we would be able to re-use it

Tankilevitch · 2024-07-27T11:29:14Z

integrations/gitlab/gitlab_integration/gitlab_service.py

+        cached_groups = event.attributes.setdefault(GROUPS_CACHE_KEY, {}).setdefault(
+            self.gitlab_client.private_token, {}
+        )


lets not use this cache, we already have a prebuilt one in ocean core

Tankilevitch · 2024-07-27T11:32:41Z

integrations/gitlab/gitlab_integration/git_integration.py

+        public_email_visibility: bool | None = Field(
+            alias="publicEmailVisibility",


enrich_with_public_email

Tankilevitch · 2024-07-27T11:33:31Z

integrations/gitlab/gitlab_integration/git_integration.py

+    filter_bots: bool | None = Field(
+        alias="filterBots",
+        default=False,
+        description="If set to true, bots will be filtered out from the members list. Default value is false",
+    )


this should be part of the group selector and not of all resources

Both Members and Groups depend on this parameter. Removing from top level means I have to include it in integration for groups and members. Please confirm this

Also, I placed it at the top level to keep a consistent behavior in this system since groups are related to user. I strictly expect the value of filterBots to be consistent for groups and members. What could go wrong is that a user might specify this parameter as false for groups kind and true for member kind. Due to the relationship between members and groups, the catalog will be populated with extra inconsistent data.

I would add a comment above the filter_bots so other developers will understand your motivation.
Also I would rename it to include_member_bots and default should be false

Tankilevitch · 2024-07-27T11:40:40Z

integrations/gitlab/gitlab_integration/gitlab_service.py

+GROUPS_CACHE_KEY = "__cache_all_groups"
+MEMBERS_CACHE_KEY = "__cache_all_members"
+
+MAX_CONCURRENT_TASKS = 30


why? how can we actually validate and handle it? we want to be able to handle the rate limits most of third parties return headers, but we don't use gitlab api straightforward but rather through the client.

https://docs.gitlab.com/ee/administration/settings/rate_limit_on_projects_api.html

https://docs.gitlab.com/ee/administration/settings/rate_limit_on_members_api.html

https://forum.gitlab.com/t/ratelimit-headers/93078

Here are some notes on the rate limits

Actually just found this one - https://python-gitlab.readthedocs.io/en/stable/api-usage-advanced.html#rate-limits which means that gitlab client handles this one for us, so we are good 👍

Tankilevitch · 2024-07-27T11:53:43Z

integrations/gitlab/gitlab_integration/gitlab_service.py

+            return
+
+    async def enrich_group_with_members(self, group: Group) -> dict[str, Any]:
+


redundant line

Tankilevitch · 2024-07-27T12:06:20Z

integrations/gitlab/gitlab_integration/gitlab_service.py

+            async for members_batch in AsyncFetcher.fetch_batch(
+                fetch_func=group.members.list,


why group.member.list and not group.member_all.list ?
https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html#id10
what do you think about adding this as an option to query all rather than only in one hierarchy?

Tankilevitch · 2024-07-27T12:08:12Z

integrations/gitlab/gitlab_integration/ocean.py

+                if selector.public_email_visibility:
+                    yield [
+                        await service.enrich_member_with_public_email(member)
+                        for member in members
+                    ]
+                else:
+                    yield [member.asdict() for member in members]


what happens when I have the same user in multiple groups? how would that behave? will I have to perform repeated upserts?

maybe in this method ^ we should use members = group.members_all.list(get_all=True) which will return all and reduce the amount of extra requests that we will have to perform?

my reason for using members as opposed to member_all was because the members_all request returns not the the user in that group but also all inherited and invited members.

Thereby resulting in all groups the same members since the members most commonly belong to the parent group - details

aside this, the behavior and how we will retrieve members does not differ from member and members_all

ok i understand what you are saying, so if we use the members_all only for the members kind wouldn't it reduce the amount of requests by a lot? as we will only have to bring the members for the root groups rather than the subgroups as well.

also just making sure that you have tested subgroups as well. please confirm

calling /members on root groups returns the same results as /members/all, calling /members on subgroups comes with less data than members/all, due to the exclusion of invited and inherited members, for root groups, concept of inherited members does not apply, all members of the root groups are returned regardless how we choose to call them.

I believe the optimization here was getting members from root groups instead of all groups (including subgroups), which would have taken more time.

Tankilevitch

Also missing webhook handling for new members.

Tankilevitch · 2024-07-27T13:33:21Z

integrations/gitlab/.port/resources/port-app-config.yaml

+          relations:
+            members: '[.__members[].username]'


I think adding members should be optional for groups, so customers will be able to decide whether they want to have it or no

and need to check that creating a new group, will sync the members correctly

fair, how about project -> group, same ?

…ests responses

… into improvement/gitlab

Tankilevitch

Nice job @mk-armah , added a few comments

integrations/gitlab/gitlab_integration/events/hooks/group.py

integrations/gitlab/gitlab_integration/events/hooks/base.py

integrations/gitlab/gitlab_integration/events/utils.py

integrations/gitlab/gitlab_integration/git_integration.py

Tankilevitch · 2024-11-12T18:13:26Z

integrations/gitlab/gitlab_integration/gitlab_service.py

+        user: User = await self.get_user(member.id)
+        member_dict: dict[str, Any] = member.asdict()
+        member_dict["__public_email"] = user.public_email
+        return member_dict
+
+    async def get_user(self, user_id: str) -> User:
+        async with semaphore:
+            logger.info(f"fetching user {user_id}")


is there more information that can be added to a member other than public email ?

Here is a sample ==> User

{ "id": 15339857, "username": "tompo", "name": "Tom Kofi Tankilevitch", "state": "active", "locked": false, "avatar_url": "https://secure.gravatar.com/avatar/81e644d6312fa802fa1a11d605104ba745732a7054be8d3579d3024ff6168bcc?s=80&d=identicon", "web_url": "https://gitlab.com/tompo", "created_at": "2023-08-27T13:39:29.744Z", "bio": "", "location": "", "public_email": null, "skype": "", "linkedin": "", "twitter": "", "discord": "", "website_url": "", "organization": "", "job_title": "", "pronouns": null, "bot": false, "work_information": null, "followers": 0, "following": 0, "is_followed": false, "local_time": null }

Member

{ "id": 15339857, "username": "tompo", "name": "Tom Kofi Tankilevitch", "state": "active", "locked": false, "avatar_url": "https://secure.gravatar.com/avatar/81e644d6312fa802fa1a11d605104ba745732a7054be8d3579d3024ff6168bcc?s=80&d=identicon", "web_url": "https://gitlab.com/tompo", "access_level": 50, "created_at": "2023-08-27T13:39:29.744Z", "created_by": { "id": 13921399, "username": "matanlevi", "name": "Matan Levi", "state": "active", "locked": false, "avatar_url": "https://secure.gravatar.com/avatar/814e5edbb657a70c5c9bd09a4171768c245d18cabec5f3b440d43dbc26d36f88?s=80&d=identicon", "web_url": "https://gitlab.com/matanlevi" }, "expires_at": null, "email": null, "membership_state": "active" }

just the socials, if its relevant

Tankilevitch · 2024-11-12T18:21:33Z

integrations/gitlab/gitlab_integration/gitlab_service.py

+        obj_dict: dict[str, Any] = obj.asdict()
+        obj_dict["__members"] = members_list


we are not consistent in the way that we are returning the enriched objects, in enrich_project you are returning objects while here you are returning dict, can you elaborate on why?

In ProjectWithMembers, we call enrich_project_with_extras after which the results are passed down to enrich_object_with_members, for enrich_object_with_members to get an object, enrich_project_with_extras needed to return an object.

Would you like me to make enrich_object_with_members to also manipulate the object directly and return a dict as well ?

Tankilevitch · 2024-11-12T18:22:26Z

integrations/gitlab/gitlab_integration/ocean.py

+                members_tasks = [
+                    service.enrich_object_with_members(
+                        project,
+                        include_inherited_members,
+                        include_bot_members,
+                        include_public_email,
+                    )
+                    for project in projects_enriched_with_extras
+                ]
+                projects_enriched_with_members = await asyncio.gather(*members_tasks)


what is making sure we are not experiencing rate limits here?

we get 20 projects, and then spawn 20 tasks and in each project it might have multiple members and then for each member batch you are performing another request.

Tankilevitch · 2024-11-12T18:23:12Z

integrations/gitlab/gitlab_integration/utils.py

@@ -45,4 +51,7 @@ class ObjectKind:
    PIPELINE = "pipeline"
    PROJECT = "project"
    FOLDER = "folder"
+    MEMBER = "member"


doesn't seems used anymore

Tankilevitch · 2024-11-12T18:26:06Z

integrations/gitlab/gitlab_integration/gitlab_service.py

@@ -451,11 +462,17 @@ async def get_group(self, group_id: int) -> Group | None:
        else:
            return None

-    async def get_all_groups(self) -> typing.AsyncIterator[List[Group]]:
+    @cache_iterator_result()


this isn't consistent, on one hand you are using @cache_iterator_result() and for users you are specifically creating cache. Ideally lets use cache_iterator_result if possible

cache_iterator_results works with generators, not coroutines...
I wrote one for coroutines here, I'll push to ocean core utils so we use it from there

Co-authored-by: Tom Tankilevitch <[email protected]>

Tankilevitch

LGTM

… into improvement/gitlab

integrations/gitlab/CHANGELOG.md

Tankilevitch

LGTM

mk-armah added 3 commits July 3, 2024 11:42

Added support for gitlab user ingestion

d3dec00

edited changelog

b88d530

edited changelog

cfeddb0

github-actions bot added the size/L label Jul 3, 2024

mk-armah requested a review from a team July 3, 2024 12:14

Tankilevitch changed the title ~~PORT-7708 | Added support for gitlab member ingestion~~ [Integration][Gitlab] Added support for gitlab member ingestion Jul 7, 2024

Tankilevitch requested changes Jul 7, 2024

View reviewed changes

Tankilevitch requested changes Jul 8, 2024

View reviewed changes

mk-armah added 6 commits July 12, 2024 10:29

Merge branch 'main' into improvement/gitlab

8a48e1b

updated group -> member relationship

81905c5

Merge branch 'main' into improvement/gitlab

58665c6

Lint

2917e45

Added error handling to get_all_group_members

9820b9a

Added error handling to get_all_group_members

24b3551

Tankilevitch requested changes Jul 25, 2024

View reviewed changes

Tankilevitch reviewed Jul 25, 2024

View reviewed changes

integrations/gitlab/.port/resources/blueprints.json Outdated Show resolved Hide resolved

Tankilevitch reviewed Jul 25, 2024

View reviewed changes

mk-armah added 8 commits July 25, 2024 19:25

Merge branch 'main' into improvement/gitlab

7d324db

updated blueprints

12ba800

Merge branch 'improvement/gitlab' of github.com:port-labs/ocean into …

191292b

…improvement/gitlab

related service to groups

9f9b706

lint

9df3202

fixed lint issues

5daceeb

change default behavior for filterBots flag

4d98b1d

made the filterBots and publicEmailVisibility flags unset by default,…

1b69d29

… defaulting to false

Tankilevitch requested changes Jul 27, 2024

View reviewed changes

Tankilevitch reviewed Jul 27, 2024

View reviewed changes

mk-armah added 13 commits September 5, 2024 11:33

updated group webhook to cater for groupswithmembers kind

fe2e7a2

Merge branch 'main' into improvement/gitlab

68354d1

remove debug logs

0a279ae

test fix

99e3724

updated webhook logic

82bfc94

revert get_group function, stick with optional response

c81ab10

added support for project members

bb7f146

checking for bot members in username works for both webhooks and requ…

0056a27

…ests responses

clean unused functions

be3dc5a

refactored codebase against DRY

c1289c7

Merge branch 'main' into improvement/gitlab

2073632

added tests

56b031c

Merge branch 'improvement/gitlab' of https://github.com/port-labs/ocean…

936f781

… into improvement/gitlab

Tankilevitch requested changes Nov 12, 2024

View reviewed changes

mk-armah and others added 4 commits November 13, 2024 09:59

Update integrations/gitlab/gitlab_integration/git_integration.py

7f98500

Co-authored-by: Tom Tankilevitch <[email protected]>

addressed comments

8df02ae

all enrichments are performed on object level directly

48329c0

remove unnecessary comment

986e9fa

Tankilevitch approved these changes Nov 13, 2024

View reviewed changes

mk-armah added 6 commits November 13, 2024 18:44

Merge branch 'main' into improvement/gitlab

5b0d7f9

removed public email querying

57ad257

Merge branch 'improvement/gitlab' of https://github.com/port-labs/ocean…

632d8c2

… into improvement/gitlab

lint

56aaaef

control resync batch size to avoid hitting rate limits

f42ee30

Added error handling for group not found

62db938

Tankilevitch reviewed Nov 14, 2024

View reviewed changes

integrations/gitlab/CHANGELOG.md Outdated Show resolved Hide resolved

Update integrations/gitlab/CHANGELOG.md

4718261

Tankilevitch approved these changes Nov 14, 2024

View reviewed changes

Tankilevitch merged commit 18adb07 into main Nov 14, 2024
18 checks passed

Tankilevitch deleted the improvement/gitlab branch November 14, 2024 16:09

		public_email_visibility: bool \| None = Field(
		alias="publicEmailVisibility",

		return

		async def enrich_group_with_members(self, group: Group) -> dict[str, Any]:

		async for members_batch in AsyncFetcher.fetch_batch(
		fetch_func=group.members.list,

		obj_dict: dict[str, Any] = obj.asdict()
		obj_dict["__members"] = members_list

[Integration][Gitlab] Added support for gitlab member ingestion #767

[Integration][Gitlab] Added support for gitlab member ingestion #767

Conversation

mk-armah commented Jul 3, 2024 • edited Loading

Description

Type of change

Screenshots

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mk-armah Jul 29, 2024 • edited Loading

Choose a reason for hiding this comment

Tankilevitch left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Tankilevitch left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mk-armah Nov 13, 2024 • edited Loading

Choose a reason for hiding this comment

mk-armah Nov 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Tankilevitch left a comment

Choose a reason for hiding this comment

Tankilevitch left a comment

Choose a reason for hiding this comment

mk-armah commented Jul 3, 2024 •

edited

Loading

mk-armah Jul 29, 2024 •

edited

Loading

mk-armah Nov 13, 2024 •

edited

Loading

mk-armah Nov 13, 2024 •

edited

Loading