-
Notifications
You must be signed in to change notification settings - Fork 44.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(blocks): Add Hubspot blocks #8786
Conversation
β Deploy Preview for auto-gpt-docs canceled.
|
β Deploy Preview for auto-gpt-docs-dev canceled.
|
PR Reviewer Guide πHere are some key observations to aid the review process:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These were alphabetically sorted lists, which helps a lot to avoid merge conflicts. Please keep this in mind in the future.
operation: str = SchemaField( | ||
description="Operation to perform (send_email, track_engagement)", | ||
default="send_email", | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why aren't these separate blocks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They don't need to be seperate blocks. I plan to update the user experience though later to show and hide inputs based on what event is being done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not familiar with Hubspot, but they seem two non-overlapping operations to me. So why are they in one block? The same goes for the HubspotCompanyBlock
and HubspotContactBlock
, which both support create/update/get operations with non-overlapping implementations.
Merging these in one block is a break of pattern regarding how we implement blocks.
It's important to get it right from the start because we currently don't have a way to make functional changes to blocks without breaking graphs where they are in use.
This PR adds the first few Hubspot blocks so we can create _real_ sales and marketing agents. ### Changes ποΈ Added Hubspot blocks; - Aded auth for hubspot - Added Company block - Added Contact block - Added Engagement block ### Checklist π #### For code changes: - [ ] I have clearly listed my changes in the PR description - [ ] I have made a test plan - [ ] I have tested my changes according to the test plan: <!-- Put your test plan here: --> - [ ] ... <details> <summary>Example test plan</summary> - [ ] Create from scratch and execute an agent with at least 3 blocks - [ ] Import an agent from file upload, and confirm it executes correctly - [ ] Upload agent to marketplace - [ ] Import an agent from marketplace and confirm it executes correctly - [ ] Edit an agent from monitor, and confirm it executes correctly </details> #### For configuration changes: - [ ] `.env.example` is updated or already compatible with my changes - [ ] `docker-compose.yml` is updated or already compatible with my changes - [ ] I have included a list of my configuration changes in the PR description (under **Changes**) <details> <summary>Examples of configuration changes</summary> - Changing ports - Adding new services that need to communicate with each other - Secrets or environment variable changes - New or infrastructure changes such as databases </details>
This PR adds the first few Hubspot blocks so we can create real sales and marketing agents.
Changes ποΈ
Added Hubspot blocks;
Checklist π
For code changes:
Example test plan
For configuration changes:
.env.example
is updated or already compatible with my changesdocker-compose.yml
is updated or already compatible with my changesExamples of configuration changes