Here is a suggestion on how to decompose the Vacancies table into Publications table also. To separate entities.

Vacancies
id
travels_id
companies_id
currencies_id
positions_id
consultants_id
categories_id
published – publication
name
experience_from
experience_to
distance
travel_ready
addresses_id
all_cities
workload_from
workload_to
lat
lng
start_date_text
date_publication – publication
date_start
date_end
introduction
task
profile
benefits_unique
price_from
price_to
jobs_ch – to remove?
slug
entity – to remove
vacancy_status – rename to status
age_from
age_to
publication_status – publication’s status
direct_link
parent_id – publication’s vacancies_id
wp_post_id – publication
date_modify
wp_post_date_modify – publication
platforms_id – ?
submitted
date_add
previews_id
active_updated_at
talent_id
wp_post_slug – publication
activated_at
last_tracking_time
new – should be replaced with Highlights
team_size
request_delete – both Vacancies and Publications
experience_level
leading_experience
process_type

Publications (suggestion)
id
vacancies_id
published
date_publication
status
wp_post_id
wp_post_date_modify
wp_post_slug
request_delete

Move some tables that are unlikely to change to PHP Enums to be used across the system.

To Enums:

• residence_permits

• currencies

• marriages

• employments

• drivers?

• languages_levels

• travels

• degrees?

• healths

• positions

• professions?

All tables should be checked for usage before removing them.

Deprecated tables:

• interviews (remove unused fields)

  • first_name

  • last_name

  • birthday

  • marriages_id

  • nationality

  • residence_permits_id

  • hobby

  • notice_period

  • available_from

  • relocation

  • distance

  • currencies_id

  • workload_from

  • workload_to

  • work_arrival

  • current_salary

  • salary_from

  • salary_to

  • products

  • auto

• interviews_blocks

• interviews_cities

• interviews_drivers

• interviews_healths

• interviews_languages

• interviews_list

• interviews_questions

• candidates_interviews_questions

• skills_interviews

• jobsch_categories (in use)

• jobsch_educations

• jobsch_employments

• jobsch_industries

• jobsch_languages

• jobsch_levels

• jobsch_positions

• jobsch_regions

• references

Here are diagrams for the current CRM and Talent databases.

Files are in uml format to use in PhpStorm. Usage instructions for Open/Save: click here.
PhpStorm doesn’t auto-save them.

CRM (PhpStorm):

rocken_db.uml

Talent (PhpStorm):

rocken_talent.uml

CRM (https://www.yworks.com/yed-live/ ):

rocken_db.graphml

Talent (https://www.yworks.com/yed-live/ ):

rocken_talent.graphml

Follow Up BI Board 03.06.2022

 Date

3 июн. 2022 г.

 Participants

• Julia

• Pavlo Chenchyk (Unlicensed)

• Miriam Koppe (Unlicensed)

• Toni

Regarding the Meeting about the BI Board i wrote down the most important points we discussed :

• First page : should be an overview. Especially about the active candidates, interviews. There should be not too many informations, 5-6 values are enough

• Second page should describe everything around KPIs. Should be reasonable and userfriendly for the consultants because that what they are working with everyday

• Next page should only show the statistics

The BI Board is only to have a view about the reports and diagrams. You shouldn`t abe able to edit anything over there. The user can edit everything inside the CRM for example to insert their KPIs.

For any questions about the procedure in the operations and whats important to display please ask Miriam Koppe (Unlicensed) or @Toni.

 Date

30 мая 2022 г.

 Participants

• Julia

• Ihor Abdrazakov (Unlicensed)

• Pavlo Chenchyk (Unlicensed)

• Miriam Koppe (Unlicensed)

• Toni

Based on the call from Monday, we discussed the following points listed down below.

The priority for the month June will be :

1. Candidate`s Email requests flow optimisation

2. Analyse unanswered requesting, check how many remain unanswered and why

3. BI – improve the visual representation and start developing as a microservice

4. Update RJ

5. Update RT

6. Complete PaaS reporting

The Task « Matching » is so far on hold. Julia will explain me how the Matching is done so far, so i will get an overview of the current state. Toni and I will plan the matching process in detail and what we will need additionally.

I have tried to list the next upcoming tasks in chronological order :

·         I will present all the last releases to the Business Managers and report them what will be done next

·         BI Board discussion is planned on Friday 11.00

·         Maike and I will exchange about implementing an Onboarding Tool

·         Limiting the skills should be implemented in the next sprint (06.05-17.05)

·         CRM reorganisation to be discussed in the end of June

·         Adding a task manager to be planned

General points:

The main idea is to process a high-level verification of the main functionality delivered to the client:

• Time to execute depends on the build scope;

• Blocker/Critical issues are a cause for the build rejection and rollback/hotfix;

• Major/Critical issues should be created in process of verification;

• Minor&Trival issues QA can create after build verification, but should add short notes to the issues list.

Tips:

• Before starting smoke verification please check that the appropriate code version has been activated on the proper testing environment;

• After smoke testing, a proper build verification status should be set into the table;

• In case a component or feature is not ready/broken after the build – please discuss this topic with PM/DEV Lead immediately (without starting Smoke verification).

We describe bug reports using two approaches:

1. Bug report as a checklist of items for small (mostly FE) issues on the certain page:

• incorrect font-family. font-size, font-weight etc.;

• incorrect color;

• incorrect size of block, image, section etc.;

• incorrect spacing between elements (text, image, section etc.);

• missing elements (image, section, block, text etc.);

• any functional issue which can be easily described without steps;

• …

example of bug report as a checklist:

https://cheitgroup.atlassian.net/issues/?jql=reporter %3D 6006f2f66aa09b006f9d0d43 and issuetype %3D Bug AND summary ~ test ORDER BY created DESC

2. Bug report as a separate issue (described in bug report template)

• Test artifacts
• Bug report instruction
• Build Verifications
• QA Automation