feat: Add Gitlab integration to ticketing vertical

[rflihxyz]

feat: Add Gitlab integration to ticketing vertical

Expected objets are:

• Collections
• Comments
• Tags
  • It is not compatible with Panora's Unified Model. The tag should be associated with the ticket (issue). However, for GitLab, tags are associated with individual projects, which makes it incompatible with Panora's Unified Model.
• Tickets
• Users

Please find details about how to build integrations here . Our discord community is also a great place to get support!

[rflihxyz]

/bounty $200

[algora-pbc]

💎 $200 bounty • Panora

Steps to solve:

1. Start working: Comment /attempt #367 with your implementation plan
2. Submit work: Create a pull request including /claim #367 in the PR body to claim the bounty
3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Additional opportunities:

• 🔴 Livestream on Algora TV while solving this bounty & earn $200 upon merge! Comment /livestream once live

Thank you for contributing to panoratech/Panora!

Add a bounty • Share on socials

Attempt	Started (GMT+0)	Solution
🟢 @neo773	Apr 17, 2024, 3:31:14 PM	WIP
🟢 @okhot	May 1, 2024, 10:09:58 PM	WIP
🟢 @Rutik7066	May 7, 2024, 8:07:18 AM	WIP
🟢 @mit-27		#434

[neo773]

/attempt #367

Algora profile	Completed bounties	Tech	Active attempts	Options
@neo773	110 bounties from 23 projects	TypeScript, Rust, Go & more		Cancel attempt

[neo773]

Can I get assigned?

[rflihxyz]

Can I get assigned?

Assigned!

[naelob]

You can find all information about Gitlab here 👍

Panora/packages/shared/src/utils.ts

Line 397 in db5d916

'gitlab': {

[webbdays]

in queue.

[webbdays]

@rflihxyz
are you still on this?

[neo773]

Yes

[webbdays]

ok.
sorry wrong mention.

[rflihxyz]

Hey @neo773 any progress on this Gitlab connector? We're available to provide help!

[neo773]

@rflihxyz
Replied on Discord!

[lakshya-dhariwal]

Is someone working on this or can I pick this up?

[neo773]

@lakshya-dhariwal
Feel free to pick this up

[jordan-ae]

@rflihxyz I want to give this a try!

[rflihxyz]

Hey @jordan-ae, just assigned you this issue, feel free to ask for help about anything here or on our Discord

@naelob

[jordan-ae]

@rflihxyz jumping on it immediately

[rflihxyz]

Don't forget to declare your attempt (instructions above) @jordan-ae

[jordan-ae]

/attempt #367

Options

• Cancel my attempt

[jordan-ae]

Don't forget to declare your attempt (instructions above) @jordan-ae

Done thanks

[Rutik7066]

/attempt #367

Algora profile	Completed bounties	Tech	Active attempts	Options
@Rutik7066	8 bounties from 6 projects	Go, Rust, Python & more		Cancel attempt

[mit-27]

Hello @naelob and @rflihxyz ,

Guildlines for creating integration issues

• It is necessary to mention what we are expecting from each unified object. Because every third party has a different implementation for the unified object. For instance, the collection object is identified as a project in GitLab.
• Also, we also have to mention what would be the expected result from Unified API endpoints for each object. This would help fellow contributors to set correct third-party endpoints.

Gitlab Unified objects Detail

• Users (ticketing/users)
  • Object in context of third-party(Gitlab) - Users
  • GET - Fetches the list of users of GitLab.
• Collections (ticketing/collections)
  • Object in context of third-party(Gitlab) - Projects
  • GET API - Get a list of all visible projects across GitLab for the authenticated user.
• Tickets (ticketing/tickets)
  • Object in context of third-party(Gitlab) - Issues
  • GET API - Get a list of issues created and assigned to authenticated users.
  • POST API - Create an issue for a specific project by providing the project ID in post data (type of UnifiedTicket object).
• Comments (ticketing/comments)
  • Object in the context of third-party(Gitlab) - Comments on issues that are created or assigned to authenticated users.
  • GET API - Get a list of comments on issues that are created or assigned to authenticated users.
  • POST API - Post a comment on an issue by mentioning ticket_id in post data (type of UnifiedComment object).

Let me know if any changes are required for any object.

[naelob]

Hello @naelob and @rflihxyz ,

Guildlines for creating integration issues

• It is necessary to mention what we are expecting from each unified object. Because every third party has a different implementation for the unified object. For instance, the collection object is identified as a project in GitLab.
• Also, we also have to mention what would be the expected result from Unified API endpoints for each object. This would help fellow contributors to set correct third-party endpoints.

Gitlab Unified objects Detail

• Users (ticketing/users)

  • Object in context of third-party(Gitlab) - Users
  • GET - Fetches the list of users of GitLab.

• Collections (ticketing/collections)

  • Object in context of third-party(Gitlab) - Projects
  • GET API - Get a list of all visible projects across GitLab for the authenticated user.

• Tickets (ticketing/tickets)

  • Object in context of third-party(Gitlab) - Issues
  • GET API - Get a list of issues created and assigned to authenticated users.
  • POST API - Create an issue for a specific project by providing the project ID in post data (type of UnifiedTicket object).

• Comments (ticketing/comments)

  • Object in the context of third-party(Gitlab) - Comments on issues that are created or assigned to authenticated users.
  • GET API - Get a list of comments on issues that are created or assigned to authenticated users.
  • POST API - Post a comment on an issue by mentioning ticket_id in post data (type of UnifiedComment object).

Let me know if any changes are required for any object.

I rea the guidelines you propose but doing so is not efficient. It means doing all the work for the contributor. This is actually the manual task to understand which object to grab from the 3rd party. If we do that no need to have contributors in the first place... It's a tricky task but this is why we have to gain it from the community.

What I propose would be a 2-sided task where 1 community member can do the detailed object information (which will be incentivized of course but < than the final task) and another one could build it upon that work.

Let me know your thoughts

[mit-27]

Hello @naelob and @rflihxyz ,
Guildlines for creating integration issues

• It is necessary to mention what we are expecting from each unified object. Because every third party has a different implementation for the unified object. For instance, the collection object is identified as a project in GitLab.
• Also, we also have to mention what would be the expected result from Unified API endpoints for each object. This would help fellow contributors to set correct third-party endpoints.

Gitlab Unified objects Detail

• Users (ticketing/users)

  • Object in context of third-party(Gitlab) - Users
  • GET - Fetches the list of users of GitLab.

• Collections (ticketing/collections)

  • Object in context of third-party(Gitlab) - Projects
  • GET API - Get a list of all visible projects across GitLab for the authenticated user.

• Tickets (ticketing/tickets)

  • Object in context of third-party(Gitlab) - Issues
  • GET API - Get a list of issues created and assigned to authenticated users.
  • POST API - Create an issue for a specific project by providing the project ID in post data (type of UnifiedTicket object).

• Comments (ticketing/comments)

  • Object in the context of third-party(Gitlab) - Comments on issues that are created or assigned to authenticated users.
  • GET API - Get a list of comments on issues that are created or assigned to authenticated users.
  • POST API - Post a comment on an issue by mentioning ticket_id in post data (type of UnifiedComment object).

Let me know if any changes are required for any object.

I rea the guidelines you propose but doing so is not efficient. It means doing all the work for the contributor. This is actually the manual task to understand which object to grab from the 3rd party. If we do that no need to have contributors in the first place... It's a tricky task but this is why we have to gain it from the community.

What I propose would be a 2-sided task where 1 community member can do the detailed object information (which will be incentivized of course but < than the final task) and another one could build it upon that work.

Let me know your thoughts

Yes @naelob, I think that would make sense. Also, we can validate the object information provided by community members to ensure that the integration will be built correctly.

[rajeshj11]

@mit-27 your changes are merged. I can't find any issue raised related to pagination. can you please provide me with the ticket?

[mit-27]

@mit-27 your changes are merged. I can't find any issue raised related to pagination. can you please provide me with the ticket?

I just checked. That was for specific provider. Can you open an issue ?

[rajeshj11]

@mit-27 your changes are merged. I can't find any issue raised related to pagination. can you please provide me with the ticket?

I just checked. That was for specific provider. Can you open an issue ?

Let the internal team raise the issue.

[algora-pbc]

💡 @mit-27 submitted a pull request that claims the bounty. You can visit your bounty board to reward.

[algora-pbc]

🎉🎈 @mit-27 has been awarded $200! 🎈🎊

• Share on socials
• Give feedback