There is a requirement to show the members and advanced count in existing recruitment analytics. We have created a new analytics API to show these details.
API endpoint - /v2/applications/analyze.json?&advancement[office_id]=630&start_date=2021-01-01&end_date=2022-12-30&access_token=XXXX
Use value key inside members object from positions_count hash for Member and use value key inside members object from advanced_count hash for ADV count. The ADV percentage should be calculated in FE.
Please refer to the following changes to VPP integration:
Add experience_type field in opportunity input. The enum options are physical, semi-remote and remote.
Exposed the experience_type in the OpporutunityType response
Added experience_type filter argument in Opportunity filter which is used in Opportunities API. This needs to be implemented in EXPA and YOP.
Added experience_type filter argument in Application filter which is used in Applications API.
Remove partly_remove filter in opportunity and applications CRM in EXPA and YOP.
Remove API endpoints(mark_opportunity_remote, unmark_opportunity_remote) which were used to mark and unmark opportunities as semi-remote on the opportunity details page.
Added experience_type to programme_fees object in committees API. This is used in the fees section on the Committees details page under the youth opportunity portal side nav
Note: In API, we also did changes in permission objects such as can_open in opportunity and can_be_remote_realized in opportunity application to use the newly added field(experience_type).
To get the list of spotlight sections use the following query query{ contentSections{ id redirect_url content_image{ filename url } } }
Opportunity and project count for SDG:
Have added both the counts in SDG API. query{ sdgGoals(active_opportunities: true){ id project_and_opportunities_count } }
active_opportunities filter is required to return only SDGs which has active opportunities. project_and_opportunities_count object will return JSON object which will have opportunities_count and projects_count.
The login CTA from aiesec.org takes to the signup page by default. Now we have added an argument called authentication_type which accepts login/signup values. Based on this value the login or signup page will be shown.
Added a new field called allow_phone_communication in MemberLead. This can be used to store if the user wants the phone number to be visible in MemberLead CRM.
Graphql API - createMemberLead New argument - allow_phone_communication
If the allow_phone_communication is true, then in the member lead response the phone and country code will be returned and if it is false, then it will be returned as null.
Note: For all the existing member leads the allow_phone_communicationis marked as false and hence the phone and country code will be returned as null.
Added a new field called custom_website_footer_url in Company.
There is no provision to update this field via API for now. This will be managed by BE team. However, in organisations and organisation API responses, the field custom_website_footer_url is exposed in the Company response.
The existing API to generate aiesec.net email fails sometimes due to timeout, duplicate username, etc.,
so, to tackle this issue, we have added a new API to check if the username given by the user is available on google. Based on this result the email generation can be carried by the
generateEmail API.
API to check the username exists: Argument: username
Currently the Member lead signup uses local offices from the MC committee page. The problem with using these local offices is some Member entities doesn't run Member lead signup programmes and these accounts are created. to tackle this we have added alignment_type in LC Alignment section. There are two types (exchange, recruitment) currently defined. recruitment alignment_type will be used in Member lead signups and exchange alignment_type will be used in YOP signup.
API changes:
Added argument alignment_type in add_lc_alignment API. Use recruitment as an option in alignment_type.
Added alignment_type filter argument in lc_alignments query. Pass recruitment as a filter option in alignment_type.
Added alignment_type filter argument in mc_alignments query. Pass recruitment as a filter option in alignment_type.
Added argument alignment_type in update_lc_alignment_label API. Use recruitment as an option in alignment_type.
Note: For existing LC alignment, no changes required. By default in Adding and querying we use exchange alignment_type.
All new objects called all_slots in OpportunityType. This object is added as a connection_type and added arguments sort arguments and start_date filter. When the date filter is selected in opportunity search page, pass that date argument in start_date filter to filter slots which are greater than the selected date. Along with this filter use sort param to sort. Use the first object from slots connection to show the start_date in opportunity card. Also added a key called opportunity_applications_count, use this key to show the applications count for that slot.
This api endpoint gives a summary of the positions - roles & departments - for an office.
Back-end
This is a REST api endpoint. It uses elasticsearch and aggregates to obtain doc_count for the particular role and department.
Front-end
The endpoint is a rest api endpoint. The roles and departments are ids which can be resolved by calling the constants query with type_id - role & department. Please do note that the roles bucket will have office_id along with it and the immediate child offices will also be returned. eg: For an MC, all its LCs will be returned, AI will have Regions returned and Regions will have MCs returned.
API has added support to store duration_type in Member Position. Currently the duration field in the form is used to calculate the end_date. Now we wanted to save the duration which can be directly used by FE platforms instead of calculation from end_date and start_date.
Mutation name: memberPositionCreate, memberPositionUpdate Input Field name: duration_id Response field : duration
Added weeklyActivitiesBulkCreate and weeklyActivitiesBulkDelete to manage project activities.
Added updateProject endpoint to update details.
To manage Enabled/Disabled use key project_enabled. This is added in createProject and updateProject endpoints.
Opportunity API changes:
added project_id argument in createOpportunity endpoint.
added projectsList endpoint to get the list of available projects. Use this to show the list of projects in projects dropdown in opportunity create form.
Added weeklyActivitiesBulkCreate and weeklyActivitiesBulkDelete to add/delete Project activities.
Exposed project object in OpportunityType.
Exposed weekly_activities object in OpportunityType. This object will have activities from both project and opportunity.
Added opportunity_type filter in opportunities API. Use this filter and pass opportunity_type as opportunity in all Opportunity crm pages in EXPA.
Added key mandatory_fields_check in opportunity type. This object will have all fields with complete check.
A REST API endpoint is created which is used to measure member leads funnel with conversion data across the recruitment status flow for an entity.
It uses elasticsearch and aggregates to obtain doc_count for different recruitment statuses.
office_id which is used for entity filter is a mandatory param that needs to be passed along with access_token. Other params that can be used are,
start_date and end_date for time period filter.
academic_level_ids for an academic level filter. It accepts the value as an array of ids which can be resolved by calling the constants query with type_id as academic_level. It is nested inside the recruitment param.
backgrounds for background filter. It accepts the value as an array of ids which can be resolved by calling the constants query with type_id as background.
employment_status_ids for employment status filter. It accepts the value as an array of ids which can be resolved by calling the constants query with type_id as employment_status. It is nested inside the recruitment param.
created_via for lead created via filter. It accepts either of the value, EXPA, expa, YOP, or yop as a string. It is nested inside the recruitment param.
motivation_reason_ids for motivation filter. It accepts the value as an array of ids which can be resolved by calling the constants query with type_id as motivation_reason. It is nested inside the recruitment param.
referral_type_ids for referral filter. It accepts the value as an array of ids which can be resolved by calling the constants query with type_id as referral_type. It is nested inside the recruitment param.
We have moved q and sort arguments into filters argument and page and per_page arguments into the pagination argument. A list of endpoints on which the changes are made can be found below,
In Accommodation query,
accommodations endpoint
page and per_page arguments are DEPRECATED and moved inside the pagination argument.
q argument is DEPRECATED and moved inside the filters argument.
In AccommodationAssignment query,
assignedApplications endpoint
page and per_page arguments are DEPRECATED and moved inside the pagination argument.
q argument is DEPRECATED and moved inside the filters argument.
In Branch query,
branchAutocomplete endpoint
q argument is DEPRECATED and moved inside the filters argument.
In Campaign query,
campaignAutocomplete endpoint
q argument is DEPRECATED and moved inside the filters argument.
In City query,
allCity endpoint
page and per_page arguments are DEPRECATED and moved inside the pagination argument.
q and sort arguments are DEPRECATED and moved inside the filters argument.
sort argument is of type enum. The value accepted here is - name.
Additionally, sort_direction argument of type enum is added. The values accepted here are - asc, desc.
cityAutocomplete endpoint
q argument is DEPRECATED and moved inside the filters argument.
In Committee query,
committees, committeesDownload, and committeesListBasic endpoint
page and per_page arguments are DEPRECATED and moved inside the pagination argument.
q and sort arguments are DEPRECATED and moved inside the filters argument.
sort argument is of type enum. The values accepted here are - name, parent_name, and tag.
Additionally, sort_direction argument of type enum is added. The values accepted here are - asc, desc.
committeeAutocomplete and myCommitteeAutocomplete endpoint
per_page argument is DEPRECATED and moved inside the pagination argument.
q argument is DEPRECATED and moved inside the filters argument.
In Constants query,
constantAutocomplete endpoint
q argument is DEPRECATED and moved inside the filters argument.
In EmployeeLead query,
employeeLeads endpoint
page and per_page arguments are DEPRECATED and moved inside the pagination argument.
q and sort arguments are DEPRECATED and moved inside the filters argument.
sort argument is of type enum. The values accepted here are - created_via, email, full_name, home_lc_name, home_mc_name, last_active, organization_name, phone_number, product_interest, qualification, referral_type, and status.
Additionally, sort_direction argument of type enum is added. The values accepted here are - asc, desc.
In Event query,
eventList endpoint
page and per_page arguments are DEPRECATED and moved inside the pagination argument.
q argument is DEPRECATED and moved inside the filters argument.
similarEvents endpoint
page and per_page arguments are DEPRECATED and moved inside the pagination argument.
In EventRegistration query,
eventRegistrationList endpoint
page and per_page arguments are DEPRECATED and moved inside the pagination argument.
q argument is DEPRECATED and moved inside the filters argument.
In MemberLead query,
memberLeads endpoint
page and per_page arguments are DEPRECATED and moved inside the pagination argument.
q and sort arguments are DEPRECATED and moved inside the filters argument.
sort argument is of type enum. The values accepted here are - academic_level_name, created_via, date_of_birth, employment_status_name, home_mc_name, lc_alignment_name, lead_name, preferred_mode_of_contact_name, referral_type_name, and status.
Additionally, sort_direction argument of type enum is added. The values accepted here are - asc, desc.
In MemberPosition query,
memberPositions and memberPositionsDownload endpoint
page and per_page arguments are DEPRECATED and moved inside the pagination argument.
q and sort arguments are DEPRECATED and moved inside the filters argument.
sort argument is of type enum. The values accepted here are - active, completed, and terminated.
Additionally, sort_direction argument of type enum is added. The values accepted here are - asc, desc.
In Notifications query,
notificationList endpoint
page and per_page arguments are DEPRECATED and moved inside the pagination argument.
In Opportunity query,
allOpportunity, allOpportunityV2, allOpportunityDownload, searchAllOpportunity, myOpportunities, and similarOpportunities endpoint
page and per_page arguments are DEPRECATED and moved inside the pagination argument.
q and sort arguments are DEPRECATED and moved inside the filters argument.
sort argument is of type enum. The values accepted here are - application, application_count, applications_closing, average_nps_score, branch_name, branches, committee, company, company_size, company_type, created_via, date_opened, departments, duration_max, duration_min, duration_type, earliest_start_date, home_mcs, host_lc_name, host_mc_name, industries, is_ge, is_gep, issues, latest_end_date, nps_score, open_to, organisation_name, price, programmes, regions, relevance, sdg_goal, sdg_target, status, sub_product, title, view_count, and work_fields.
Additionally, sort_direction argument of type enum is added. The values accepted here are - asc, desc.
In OpportunityApplication query,
allOpportunityApplication, allOpportunityApplicationDownload, unbilledApplications, and applicationTestimonials endpoint
page and per_page arguments are DEPRECATED and moved inside the pagination argument.
q and sort arguments are DEPRECATED and moved inside the filters argument.
sort argument is of type enum. The values accepted here are - applicant_name, average_score, date_an_signed, date_approved, date_matched, date_realized, duration_type, experience_end_date, experience_start_date, favourite, flight_date, graduation_date, has_started_standards_survey, home_lc_name, home_mc_name, host_lc_name, host_mc_name, is_gep, last_active, ldm_grade, nps_grade, opportunity_id, organisation_name, opportunity_title, paid_at, partner_type, product, required_backgrounds_percentage, required_skills_percentage, sdg_goal, sdg_target, slot, status, sub_product, and scheduled_interview.
Additionally, sort_direction argument of type enum is added. The values accepted here are - asc, desc.
In OrganizationDevelopment query,
organizationDevelopmentList endpoint
q argument is DEPRECATED and moved inside the filters argument.
In Page query,
pages endpoint
page and per_page arguments are DEPRECATED and moved inside the pagination argument.
q and sort arguments are DEPRECATED and moved inside the filters argument.
sort argument is of type enum. The value accepted here is - title.
Additionally, sort_direction argument of type enum is added. The values accepted here are - asc, desc.
In People query,
allPeople, allPeopleDownload, myPeople, and personApplications endpoint
page and per_page arguments are DEPRECATED and moved inside the pagination argument.
q and sort arguments are DEPRECATED and moved inside the filters argument.
sort argument is of type enum. The value accepted here is - aiesecer, application, contacted_at, contacted_by_name, dob, follow_up_name, followed_up_at, full_name, gender, home_lc_name, home_mc_name, interviewed, interviewed_at, last_active_at, lc_alignment_name, professional_experience_in_years, referral_type, selected_programmes, and status.
Additionally, sort_direction argument of type enum is added. The values accepted here are - asc, desc.
colleagueAutocomplete endpoint
q argument is DEPRECATED and moved inside the filters argument.
In PeopleAutocomplete query,
peopleAutocomplete, peopleAutocompleteColleagues, peopleAutocompleteEmployees, and peopleAutocompleteActive endpoint
q argument is DEPRECATED and moved inside the filters argument.
In TagListAutocomplete query,
tagListAutocomplete endpoint
q argument is DEPRECATED and moved inside the filters argument.
In Todo query,
todos endpoint
page and per_page arguments are DEPRECATED and moved inside the pagination argument.
The code is backward compatible. If both arguments (new and deprecated) are present in a query, a value from the new argument will be considered to get the result.
In the branch mutation following mutations will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the opportunity mutation following mutations will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the memberLead mutation following mutations will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the memberPosition mutation following mutations will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the page mutation following mutations will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the pageComponent mutation following mutations will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the questionnaire mutation following mutations will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the slot mutation following mutations will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the employeeLead mutation following mutations will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the branch query following queries will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
getBranch -> branch
Additionally, "myBranch" query will be DEPRECATED. Use "my" boolean argument in "branches" query instead and set the value as true to get the current user's managed data.
The default value for "my" boolean argument is false.
In the clientData query following queries will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the constants query following query will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the employeeLead query following query will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the lcAlignment query following query will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the memberLead query following queries will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the memberPosition query following query will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the suggestedCountry query following queries will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the tagList query following queries will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the person query following queries will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones.
allPeople -> people
allPeopleDownload -> downloadPeople
getPerson -> person
personPaymentCreate -> createPersonPayment
personPaymentDelete -> deletePersonPayment
Additionally, "myPeople" query will be DEPRECATED. Use "my" boolean argument in "people" query and set the value as true to get the current user's managed data.
The default value for "my" boolean argument is false.
Apart from the following mentioned details all the arguments and functionalities are intact.
For person query,
id is made a required argument.
For createPersonPayment query,
id is made a required argument.
created_by and action_for argument are removed as it is not used for making any change in the person record.
Duration, salary, and additional details for any partly remote opportunity can now be added from updateOpportunity mutation and is removed from opportunityMarkRemote. This is done to provide the ability for LC and MC to edit partly remote details.
Under the `opportunity` argument, the `remote_experience_details` argument will contain the following three inputs,
remote_experience_duration
remote_experience_salary
remote_experience_additional_details
All three inputs are required if `remote_experience_details` argument is used.
The exposed field are `remote_experience_duration`, `remote_experience_salary`, `remote_experience_additional_details`.
Sample request,
mutation{
updateOpportunity(id: 14620, opportunity: {
remote_experience_details: {
remote_experience_duration: "<div>Total duration will be of 6 months</div>",
remote_experience_salary: "<div>$200 and $300 per month for remote and on-field work resp.</div>",
remote_experience_additional_details: "<ol><li>Minimum of 2 months of on-field work is mandatory</li><li>Have a bank account which accepts international payments</li></ol>"
}
}) {
id
remote_opportunity
remote_experience_duration
remote_experience_salary
remote_experience_additional_details
}
}
In the organisation mutation following mutations will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
In the organisation query following queries will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
allOrganisation -> organisations
allOrganisationDownload -> organisationDownload
getOrganisation -> organisation
Additionally, "myOrganisation" and "organisationAutocompleteMy" queries will be DEPRECATED. Use "my" boolean argument in "organisations" and "organisationAutocomplete" queries respectively and set the value as true to get the current user's managed data.
The default value for "my" boolean argument is false.
In the committee query following queries will be DEPRECATED and are renamed with the new ones. Kindly replace them with the new ones. All the arguments and functionalities are intact.
getCommittee -> committee
getCommitteeBasicDetails -> committeeBasicDetails
getCommitteeTerm -> committeeTerm
Additionally, "myCommitteeAutocomplete" query will be DEPRECATED. Use "my_committee_autocomplete" boolean argument in "committeeAutocomplete" query instead and set the value as true to get the current user's managed data.
The default value for "my_committee_autocomplete" boolean argument is false.
Country and Alignment fields: Use the following API to get the list of countries and the alignments. Which ever country is selected the respective mc_aligments has to shown in alignment field. When submitting the form, along with alignment_id selected the id inside lc object should also be sent in the request. query{ mcsAlignments{ id name label mc_alignments{ id keywords lc{ id } } } }
Added New API to check if the Lead is present. This is to be used in customer facing application. When the user enters the email id pass this argument to memberLeadCheckIfExists API endpoint. This will return either entity_not_found or entity_already_exists in response object for key name sub_code.
Note: We have added new types to constants. employment_status, preferred_mode_of_contact, academic_level, referral_type . Use the constants from these types in create, update and show for the following (employment_status_id, preferred_mode_of_contact_id, academic_level_id, referral_type_id) fields in Member Lead.
Checklist: There are two mutations added to bulk create checklist and creating responses for the checklist. mutation: Add member_lead mutation with params id which should be the committe id.
mutation { memberLeadChecklistQuestionBulkCreate(id: 1,checklist: [{ question_text: "Are you a volunteer updated", description: "new updated description 1" }, { question_text: "Are you having a passport updated", description: "new updated description 2" } ] ){ id description question_text question_type survey } }
To add response use memberLeadChecklistResponseCreate with the params id, survey_id, and answers where member_lead id should be passed in id and survey id should be passed in survey_id
To list all checklist question use the query getChecklistQuestion with params id where you should pass committe id Eg:
query{
getChecklistQuestion(id: 1){
id
question_text
question_type
description
}
}
FrontEnd need to check the member_lead whether they have permission to create checklist_response, to check this there is a permission added inside member_lead types called can_fill_checklist which returns boolean value, if its return true then the frontend can allow the user to create response.
We had 2 copies of the same component for a page - one as draft and the other as published. Under this new change, the draft items will be removed and will be saved in the same row as the published item. This will reduce the number of items in the table by a lot.
Back-end The change entails having to manage the creation and handling of the component to create and provide the data correctly. The creation and updation of the component involves having to map the input data to their draft columns so that the FE doesn't need to change anything. The deletion of a component will contain nullifying the content, position etc of the draft and flagging it as deleted but the published will stay as is. Once the draft is published, if the delete is flagged, the entire component is deleted.
While publishing the component, the contents of the draft columns will be copied to the publisher columns. Any subsequent edit happens in the draft columns.
Front-end The change to be made by the front end is during fetching of the components. The creation, updation and deletion of the component remains the same. The thing to note is that since the published and draft are no longer different components, there will only be one id or client_reference_id whichever is being used.
The keys for fetching data remains unchanged - content, component_type, position and component_attachment.
The keys remain unchanged for the FE. The response depends on the input. For component creation and updation the draft items will be provided and for page query, the status determines what to respond with.
Sample query
query { getPage(id: 2965) { title status page_components(status: "draft") { edges { node { id content position component_type } } } } }
Sample mutations
Create component
mutation { pageComponentCreate(page_id: 2965, page_component: { content: "mnop", component_type: "text" }) { id position content } }
Update component
mutation { pageComponentUpdate(id: 29652, page_component: { position: 2 }) { id position content } }
Delete component
The component is deleted. The response would be null. But during the page query, this component will be present with its content until published again.
mutation { pageComponentDelete(id: 29652) { id } }
We have revamped the manage committee section in EXPA and this causes breaking changes in current_positions object. current_positions returns the list of position a person holds in EXPA.
This changes affects both REST and Graphql API type.
Graphql API changes: We have added new object called member_positions in current_person type. This object will have newly added fields related to positions. This object should be used instead of current_positions
Sample Request: query ProfileQuery { currentPerson { id member_positions{ id start_date end_date status ldm_report title role{ name } function{ name } committee_department{ name } duration{ name } } } }
We had changed the auto complete query API name for tag from TagListAutocomplete to tagListAutocomplete . This is to mainly follow Graphql naming convention. This was the only autocomplete API endpoint changes and rest of the autocomplete names already follow Graphql naming convention.
This feature is a revamp to the existing positions to make it more manageable and analyzable.
Back-end
There is the MemberPosition model which contains the detail of each position. It has 3 states - active, completed and terminated. Each position has a role, function and department assigned to an office along with the start and end date for the responsibility. If a position is terminated, a reason has to be provided.
Front-end
There are create and terminate mutations as well as queries to fetch one, all or download the positions.
The functions, roles, exit reasons and degree level can be queried using the Constants query. The type_id are function, role, exit_reason, study_level. The id from this query is the value for role_id, function_id and exit_reason_id in the mutations. A sample query is below.
query{
allConstants(type_id: "role"){
id
name
}
}
Mutations
1. memberPositionCreate - This is used to create a position. Please note that reports_to_position_id is required for everyone other than president.
For department, there are two arguments committee_department_name and committee_department_id . When adding LCVP initially, use committee_department_name and when adding LCVP to an existing department section, use committee_department_id.
reports_to_position_id is the member position of the person who reports to. If the role is for a VP, then the reports_to_position_id will be the id of the member_position object for the President.
Note: focus_products field is dependent on function field. for selective functions focus product applicable. For this, look for the key called has_focus_products in functions response(allConstants). This will return "true" or "false". Based on this value show the focus product input.
3. memberPositionTerminate - Used to terminate a member position. Exit reason id is required. The id can be obtained from constants with type_id exit_reason. Sample constant query above. If the exit reason is Other, then other_exit_reason has to be provided.
mutation {
memberPositionTerminate(id: 1, exit_reason_id: 11667, other_exit_reason: "Just for fun") {
id
status
exit_reason {
name
}
other_exit_reason
terminated_at
terminated_by {
id
}
}
}
Queries
1. memberPosition - This fetches a single member position. Id is required
query {
memberPosition(id: 1) {
id
}
}
2. memberPositions - This query fetches all member positions and is used for analytics. Filters are available. The columns to sort by are ["gender", "no_of_ixps", "is_ixp", "status", "start_date", "dob", "end_date", "office_name", "exit_reason", "role", "department_department", "study_levels", "reports_to_name", "full_name", "function_name"]
query {
memberPositions(filters: {status: ["terminated"]}) {
paging {
total_items
}
data {
id
}
}
}
3. memberPositionsDownload - This query adds an export task which will be sent to the email id of the requesting person. All the available columns are in the query. The filters can be applied here as well.
4. committee - A new API to return member_positions has been added.
query{ committeeTerms(id: 630){ id name member_position{ id } committee_departments{ total_count edges{ node{ id name member_positions{ edges{ node{ id } } } } } } } }
query{ committeeTerm(id: 630, term_id: 11471){ id name member_position{ id } committee_departments{ edges{ node{ id name member_positions{ total_count facets edges{ node{ id role{ name } } } } } } } } }
5. VP count in Department accordion - To get the VP count, refer facets objects inside member_positions object.
facets - {21755=>8, 21756=>187} . 21755 is role_id. use local storage for role_id and 8 is total count. for AI - use role AIVP, for Region use role RD, for MC use role MCVP. and for LC use role LCVP.
We have added remote_realization_broken status in remote opportunity flow. An application can be moved to remote_realization_broken from remote_realized.
Recommended changes on user interfaces
Customer Facing Applications
If you are showing a timeline of an application, you must now represent remote_realization_broken by checking for this status.
When filtering data for remote realized broken applications, you must also pass "remote_realization_broken" in the filters as well.
Internal Applications
If you are showcasing statuses of applications or people in a list, you must account for remote_realization_broken status
If you are showcasing the profile of a particular application, you must check for the status remote_realization_broken
If you are showcasing a timeline, you must check for the remote_realization_broken status.
You must add remote_realization_broken status as a filter on all lists for people and applications.
Added break_remote_realization mutation to mark application as remote realize broken.
Added permission object can_break_remote_realization in OpportunityApplication permission.
Added date_remote_realization_broken_at and remote_realization_broken_by in ApplicationMeta .
Before the premium partners were identified using an object called is_gep. If this object is true then it is considered as Premium partner. Now we have added a new field called partner_type. This will have either global or regional as value.
Make these changes in following places:
Application filter:
Remove is_gep and add partner_type.
Organisation Filter:
Remove is_gep and add partner_type.
Opportunity filter:
Remove is_gep and add partner_type.
Organisation details page:
Remove is_gep and add partner_type.
Organisation Mutation:
Remove is_gep from updateOrganisation and createOrganisation API.
Added new API endpoint to mark partner type in organisation
When marking an opportunity remote, it will now accept the `remote_experience` argument in `opportunityMarkRemote` mutation which will contain the following three inputs,
remote_experience_duration
remote_experience_salary
remote_experience_additional_details
All the arguments are required.
The exposed field are `remote_experience_duration`, `remote_experience_salary`, `remote_experience_additional_details`.
Sample request,
mutation{
opportunityMarkRemote(id: 14620, remote_experience: {remote_experience_duration: "<div>Total duration will be of 6 months</div>", remote_experience_salary: "<div>$200 and $300 per month for remote and on-field work resp.</div>", remote_experience_additional_details: "<ol><li>Minimum of 2 months of on-field work is mandatory</li><li>Have a bank account which accepts international payments</li></ol>"}){
id
remote_opportunity
remote_experience_duration
remote_experience_salary
remote_experience_additional_details
}
}
This feature aims at setting and tracking the achievements of the entities of AIESEC.
How it works
There will be plans for an entity to which the target is updated. The targets will be uploaded via an xlsx file which will contain the info of the programme and the targets for each programme and the various stages of applications. Only when the template is uploaded will the data be available in the analytics.
The achieved data is calculated on the first upload and then on every further update to an application. This is to ensure that the data is consistent and real-time.
The goal type - sign_ups will always return the total since its only based on home office.
Back-end
There are plans which has a start month and end month. Each entity has a deadline by which the entity has to upload a plan. The deadline will be set by the parent entity. The template will be processed and data will be entered into entity goals which will specify the type, programme and other details for that particular target.
Once the template is imported, the calculation for the targets created will be triggered. The achieved info of the goal will be updated. This calculation also happens for a particular goal when an application is updated.
The data can be fetched via analytics and it returns a list of entity goals. Filters are available for filtering necessary data. FE is expected to do the final calculation and consolidation.
Front-end
FE has access to multiple API's to facilitate this. The set deadline and file import mutation and entity plans and entity goal setting query for analytics will provide all the necessity needed by FE.
1. entityPlans - This query is used to fetch the plans for the entity. Upcoming is an optional parameter. If upcoming is false, it will show only the current plans. If upcoming is true, then the return data will only be the upcoming plans.
query { entityPlans(office_id: 1585, upcoming: true) { deadline file_import { url filename status creator { id full_name } } office { id } plan { id start_month end_month mc_deadline lc_deadline(office_id: 630) } } }
2. planSetDeadline mutation - This mutation is used to set deadline to a plan. If an MC is setting the deadline, it'll be applicable for all the LCs under it. If AI set the deadline, that is the deadline for all MCs.
mutation { planSetDeadline(office_id: 1585, plan_id: 1, deadline: "10-02-2020") { id start_month end_month name mc_deadline lc_deadline(office_id: 630) } }
3. fileImport mutation - This endpoint is used to upload all xlsx, csv type files and process the data. Its a general purpose endpoint and require FE to specify the type of file uploaded. For entity goals, FE should also pass in plan_id and office_id to meta in the input.
4. entity_goal_setting query - This is the query for analytics. Its not currently paginated and raw data is provided. Filters are available but consolidation of data is expected to happen at the FE.
query { entityGoalSetting(office_id: 1585, programme_id: 1, exchange_type: incoming, opportunity_duration_type_id: 1, sub_product_group: information_technology_engineering, time_period: {from: "", to: ""}) { office { id } programme { id } exchange_type opportunity_duration_type { id duration_type } sub_product_group goal_type goal achieved } }
Have added additional details in the survey question. These object will have keys like sub_question_type, visual_style, is_other .
sub_question_type will have either ["detractor","passive"] or ["passive","promoter"] value. According to this value the step 2 and step 3 questions are showed.
visual_style will have vertical value which indicates how that questions are aligned.
is_other will have true value.If this option is selected then and input field should appear and the user enters the value. For these cases we have two additional params (other_question_id, other_option_answer) .
For Membership LPS and Membership NPS surveys, in api new object added position is added. This will have details for person name, person home mc name, profile picture, position name and position office id. current_position key is also removed from the response and the details of this can be taken from name inside position object.
For Youth LPS and Youth NPS surveys, in api new object added opportunity_application is added. This will have details for person name, person home mc name, profile picture, opportunity title and opportunity home MC id.
We have added a new status called finished for applications (opportunity_applications).
Before we considered an application as finished if an application status is realized and the experience_end_date is in the past.
Recommended changes on user interfaces
Customer Facing Applications
If you are showing a timeline of an application, you must now represent finished by only checking for the status rather than checking for realised and experience_end_date.
When filtering data for applications that are in the past or completed, you must also pass "finished" in the filters as well.
Internal Applications
If you are showcasing statuses of applications or people in a list, you must account for finished being a status rather than checking for realised and experience_end_date
If you are showcasing the profile of a particular application, you must check for the status of finished rather than checking for realised and experience_end_date
If you are showcasing a timeline, you must check for the finished status.
You must add finished status as a filter on all lists for people and applications.
We have added a feature in Sales CRM which will allow import data by Uploading Import sheet in either CSV or Excel format. This way more leads can be added.
Mutation to import file Mutation: fileImport Params: import_type: "employee_lead", import_file: { filename: "Employee_lead.csv", content: "To base 64 converted file" }
Eg: The following will be the example for the above mentioned mutation to process records when uploading sheets. Sample mutation
Before creating csv file or excel make sure the file has a required headers to process.
Employee_lead csv should have following headers Lead Name Job Role Work Email Phone Country Code Mobile Organization Name Organization Type ID Industry ID Product Interest ID Referral Local Committee ID Invite To POP ( True or False or Nil )
Before in remote realize feature we tracked remote start date and remove end date. Now, in API remote_realized status is added and will be updated with this status for the applications which are being marked as remote_realized.
We have added this status which will help us get these stats in analytics.
Recommended changes on user interfaces
Customer Facing Applications
If you are showing a timeline of an application, you must now represent remote_realized by checking for this status.
When filtering data for remote realized applications, you must also pass "remote_realized" in the filters as well.
Internal Applications
If you are showcasing statuses of applications or people in a list, you must account for remote_realized status
If you are showcasing the profile of a particular application, you must check for the status remote_realized
If you are showcasing a timeline, you must check for the remote_realized status.
You must add remote_realized status as a filter on all lists for people and applications.
There was a requirement of having to freeze an office or unpublish opportunties. The governance actions was made for this purpose.
How it works
Only AI members have the power to unpublish an opportunity. This can be done by providing a reason out of a list of constants of type unpublish_reason. The freezing of office also results in the opportunities under it getting unpublished. The reason in this case would be OfficeType Frozen.
The freezing and unfreezing of office is done by letting the team know. Once frozen, the currently active president will receive a mail. If its an LC then both the LCP and MCP will receive a mail mentioning the same. For an MC, all the LCS under it would be frozen as well. Once an office is frozen, all the opportunities under that office will also get unpublished.
Front-End
There is an existing API for unpublishing an opportunity. The change made was to the permission as well as to provide a reason and any other remarks. The reason can be selected using the constants query with type unpublish_reason. This id has to be passed as the reason for unpublishing.
opportunityUnpublish(id: 1, reason_id: 10, remarks: 'Just for fun') { id status }
The reason_id can be obtained using the constants query.
allConstants(type_id: 'unpublish_reason') { id }
Exposed is_frozen in OfficeType - This will return true or false. Use this object to know the status frozen status of committees.
We have revamped the Graphql errors in Graphql standards, returning 200 response codes with errors as messages in response.
Old error codes:Currently the restructuring of graphql errors were done for the following error types:
In build errors:
ActiveRecord::RecordNotFound
ActiveRecord::RecordInvalid
ActiveRecord::StatementInvalid
ActiveRecord::RecordNotUnique
Custom errors:
EntityNotFound
InvalidRecord
All internal server errors(status code - 500) are also rescued and presented to the frontend. This particular response will include the rollbar id for the error to easily debug it.
The above-mentioned errors do go through Graphql API endpoints and are being rescued. There are two other scenarios where we check a few validations before the API endpoint is triggered. These errors are not rescued now and require infrastructure change which will also impact Rest endpoints. The following are those scenarios:
Invalid Account Type - This is used to determine which user can access which platform. Example scenario. YOP users should not be able to access EXPA.
Invalid Access Token - When the provided access token is invalid.
To fix the above two scenarios we will need to have an infrastructure update to Graphqh. We can take this forward in the future.
Note: The error codes which will remain the same are 401 and 406.
Sample Request & Response:
1. ActiveRecord::RecordNotFound:
Request: query getApplicationQuery { getApplication(id: 628134) { id } }
We have the EXPA CRM which can be used to view the details of various stuff such as Opportunities, Applications, People, Offices and Companies. But it was mentioned to be difficult to handle and use the data effectively from EXPA. So a downloadable version of the data was required. This feature is built to provide a downloadable link for all the data available in EXPA CRM.
How it works
The link to the download will be available in the respective CRM page in EXPA. Each file can contain a maximum of 5000 rows of data (5000 records).
The front-end side will hit the required API endpoint along with columns as well as the other filters that were available for the CRM. The back-end will queue the request and execute it as a background task while responding to the api with 200 and a message informing that the request is queued.
The back-end will then generate an excel which contains the records based on the filters and other request data provided. This excel file will then be uploaded to Amazon S3 where it will stay for 48 hours. The link will then be mailed to the email address of the user who requested the download. The link in the email is valid for 48 hours, after which the file would be deleted.
Front-end
The front-end has to call the API endpoints with the column names as well as the other required filters. Please find the column names below.
The Graphical analytics used to return Total applications , approved , realized, finished and completed count. Now in API added two more data count.
1. Total Signups - The value of this can be found in the key total_signups 2. Total Accepted - The value of this can be found in the key total_an_accepted
We have deprecated POST /v2/people/{:person_id}/contacted endpoint which will update the EP contacted at details. This was an old endpoint and this is now part of EP Followup .
The alternate for this endpoint:
Endpoint: updatePerson Param: follow_up_id
The followup options can be get form the following endpoint: query{ allConstants(type_ids: ["ep_manager_follow_ups"]){ id name } }
Sub Product is part of new Opportunities and this filter is now being added to performance analytics which will filter out ICX data from opportunity, applications from opportunities under the selected sub products.
Filter name: sub_product_ids Filter type: Array, accepts multiple Integer values. Filter option: Fetch available sub products from subProducts Graphql API query.
Duration type is part of new Opportunities and this filter is now being added to performance analytics which will filter out ICX data from opportunity, applications from opportunities under the selected duration type.
Note: 1. This same format applies for all the other statuses also - applied, matched, an_accepted, approved, realized, finished, completed 3. The number value added now are the programmes ids. 1 - Old GV 2 - Old GT 5 - GE 7 - New GV 8 - New GT(GTa) 9 - GTe
We have added a feature in a way that will let the users to add custom data to a person or an application.
This way custom clients can store information for users and applications in a secure manner only accessible to that client. Some examples might be preferences such as timezone, language, last online, etc.
Mutation: clientDataPut - This is a create mutation clientDataUpdate - This is an update mutation
Currently clientData can be added to person and application and thus these records are returned in CurrentPersonType, OpportunityApplicationType as client_datas as connection_type
Sample request: mutation{ clientDataPut(client_data: {applicable_id: 1, applicable_type: "Person", name: "foo", value: "bar", data_type: "String"}){ id data_type name value } }
Reason: We have revamped both Performance and E2E analytics to serve the response fast. These change has been implemented in EXPA analytics. We could still see few analytics requests in our logs with old params for performance and E2E and this is affecting other analytics requests. We have planned to remove the support for old analytics params and this way the other requests are served faster.
Recommended Solution:
Performance Analytics: Old param - performance New param - performance_v3 Sample request: https://analytics.api.aiesec.org/v2/applications/analyze.json?access_token=****&start_date=2019-05-29&end_date=2020-01-01&performance_v3[office_id]=1626
E2E Analytics: Old param - e_to_e New param - e_to_e_v1 Sample request - https://analytics.api.aiesec.org/v2/applications/analyze.json?access_token=****&start_date=2020-01-01&end_date=2020-08-05&e_to_e_v1[person_committee]=1585&e_to_e_v1[opportunity_committee]=1609&e_to_e_v1[status]=accepted&programmes[]=1
Deprecation Date: 7th August 2020
Note: After the deprecation date if the endpoint is still accessed with old param the response code will be 410 and there will not be any data returned.
The signup in aiesec.org is carried out in two ways. 1. Signup through aiesec.org 2. signup via API endpoint.
Signup via API endpoint support additional fields along with the mandatory fields. One of the field is selected_programmes and this is to mark the product interest fo the Signup account. This field used to accept values like 1, 2, 5. These are the programme ids. We have stopped support for old programmes and thus allow only new programmes 7, 8, 9.
If any of the old programme Id is passed in selected_programmes the API will respond with Validation error.
Sample error response for old programme id : Status Code: 422 Response: {
"errors": {
"selected_programmes": [
"Old products are not supported anymore. Please use the new products - 7, 8, 9"
]
}
}
Please change the value to new programme ids for successful signups.
New programme Ids: 7 - Global Volunteer 8 - Global Talent 9 - Global Teacher
Added mutation for create, update and destroy. engagementCreate, engagementUpdate, engagementDelete
Added can_add_engagement permission object in EmployeeLeadPermissionType
Added can_update and can_delete permission objects in EngagementPermissionType.
Exposed engagements as connections in EmployeeLeadType
Lead Qualification:
Added fields budget, authority, need and timing in EmployeeLeadInput, EmployeeLeadType and EmployeeLeadFilter
added field qualification_score in EmployeeLeadType which will return the percentage for true value in budget, authority, need and timing fields.
Status time tracker
added field status_last_updated_at in EmployeeLeadType which will return the timestamp for the latest status update.
Note: 1. budget, authority, need and timing are boolean type but the UI will have options like Yes, No. 2. meeting date and meeting time will be two different fields in UI but it will be one field in API - engagement_date
We have added remote_opportunity flag to differentiate certain opportunities. This key is now being exposed in response of OpportunityType. this will be used by the YOP application to show additional information.
key - remote_opportunity type - String possible options - "true", nil
Deprecated field: opportunity_cost in OpportunityType
Reason: opportunity_cost used to return exchange participation fee and project fee. With new opportunity flow we geocode the users location and return the project fee and participation fee according to their location. Now we have a requirement to return the users home MC health insurance details. For this we have deprecated this and added a new object with same response.
Recommended solution: Use the fee_and_health_insurance instead of opportunity_cost and this new object will return all the data from opportunity_cost along with health_insurance_link in its response.
When reporting an opportunity, it is now possible to pass in additional information specially when the reason is other by using the "additional_information" argument in the "opportunityReport" mutation
Reason: Currently the opportunity can be created for any Local committee irrespective of the user's role.However this opportunity will not show up for the user if they dont manage that committee. To tackle this issue we have scoped out the committees that the user manages and listed out in current_person response. This can be shown in the Host LC dropdown in opportunity create.
Deprecated field: accommodation_covered of LogisticsInfoInput in OpportunityInput.
Reason: accommodation_covered field is defined as Boolean type and with New opportunity creation flow for new products/programmes this field will have values other than Boolean. The reason why we didn't add a new field and changing the existing field input type is this field is being used in existing opportunity and this is also part of new opportunity flow.
Recommended solution: Fetch the latest schema query and update the accommodation_covered input field type to String.
Reason: We are improving the response type to be standardised with attachments. This will also return the name of the cover photo image along with the URL rather than just the URL. Due to some features being deployed on EXPA, it is important that we deploy this change to production without giving much notice.
Reason: branch_id is no longer a required parameter in the opportunity creation flow as per the new programme structure and hence we cannot readily provide an organisation.
Recommended solution: Use the branch.company to get the name of the organisation or any other details of the company/organisation that is hosting the opportunity.
Date of deprecation: 27th May 2020, after this, you will see a notice in development consoles that the field has been deprecated. If an opportunity does not have a branch associated with it during creation and you request for the organisation, the API will throw a 500 error.
Date of removal: 30th June 2020, after this, the field will no longer be available on the OpportunityType
