set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

You should not be setting the global CMAKE_CXX_STANDARD, it can cause subtle issues. The modern CMake way of doing this is technically figuring out each individual feature you actually require, though libraries/functions from stdlib are gated through version numbers anyway, so normally it's something like:

target_compile_features(protoTaskPlanner PUBLIC cxx_std_23)

You can find a list of features here: https://cmake.org/cmake/help/latest/command/target_compile_features.html

include(FetchContent)

FetchContent_Declare(
    genericDictionary
    GIT_REPOSITORY https://github.com/pacmaninbw/GenericDictionaryHeaderLibraryGeneric.git
    CMAKE_FIND_PACKAGE_NAME GenericDictionaryHeaderLibraryGeneric
)

FetchContent_MakeAvailable(genericDictionary)

You should not be attempting to create your own buildsystem here, you own the repo, you own the project, make your project installable in CMake, so that you can just cmake install your library, and use

find_package(genericDictionary CONFIG REQUIRED)

your own package, which will also allow you to integrate it into VCPKG (or conan) so you can just use a package manager to manage everything including your boost installation. Fetch content causes issues in offline environments as well and makes build replication much more difficult.

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -pedantic")

This can cause issues with third party libraries (unless you specify system libraries in CMake, which only kind of works in some cases). Do this instead:

target_compile_options(protoTaskPlanner PRIVATE -Wall -Wextra -pedantic)

Additionally, as it stands, this will cause warning messages and could fail to compile on platforms with out these compile arguments. So you'll want to use generator expressions to stop this from being an issue:

    target_compile_options(protoTaskPlanner PRIVATE
        $<$<OR:$<CXX_COMPILER_ID:GCC>,$<CXX_COMPILER_ID:Clang>>: -Wall -Wextra -pedantic>
        #roughly equivalent
        $<$<CXX_COMPILER_ID:MSVC>: /Wall>
    )

This does not pass the sniff test.

if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/PrivateData/dbadmindata.h")
    add_compile_definitions(USINGPRIVATECONNECTIONDATA=1)
endif()

Why would, in a repo you control, a header file just seemingly not exist sometimes? This is basically something that should never happen. Is it supposed to be a library? Well then it should be find_package-able and not be conditionally included in the source of your library. Is it generated? Where is the generator commands in your CMake file, something CMake is wholly capable of doing and doesn't need random bash scripts to make happen? Is it a version thing? That needs to be handled by Git, not by CMake.

Regardless, you should be using target compile definitions, not global versions.

target_compile_definitions(protoTaskPlanner PRIVATE USINGPRIVATECONNECTIONDATA=1)

And if this is a legit optional thing (not some code source horror thing going on that should never happen with conditional source files), then you need to use CMake options.

option(PROTO_TASK_PLANNER_USING_PRIVATE_CONNECTION_DATA "your text telling people what this does" OFF)

Also, you should be pseudo namespacing not only your CMake variables, but also all you preprocessor definitions. I can count on my hand the number of times that's screwed things up, but when it did, it was awful. Macros can't be trusted to not be pseudo namespaced, so don't act like they can. Also there's no sensible coding style that warrants a macro name being squished with out any semblance of what each word is, just use YOUR_NAMESPACE_USING_PRIVATE_CONNECTION_DATA instead. Then you can check later.

if(${PROTO_TASK_PLANNER_USING_PRIVATE_CONNECTION_DATA})
    target_compile_definitions(protoTaskPlanner PRIVATE YOUR_NAMESPACE_USING_PRIVATE_CONNECTION_DATA=1)
endif()

There's no reason for this:

add_executable(protoTaskPlanner
    main.cpp 
    PTS_DataField.h PTS_DataField.cpp 
    UserModel.h UserModel.cpp TaskModel.h TaskModel.cpp ModelBase.h ModelBase.cpp
    DBInterface.h DBInterface.cpp
)

to not be neatly organized into something like this:

#note you can also separately add sources using target_sources
add_executable(protoTaskPlanner
    main.cpp 
    PTS_DataField.h 
    PTS_DataField.cpp 
    UserModel.h 
    UserModel.cpp  
    TaskModel.h 
    TaskModel.cpp 
    ModelBase.h 
    ModelBase.cpp
    DBInterface.h 
    DBInterface.cpp
)

This:

target_include_directories(protoTaskPlanner PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/build/_deps/genericdictionary-src)

is extremely sketchy. This again, looks like you're doing some code generation outside of CMake (this file path does not show up in your repo, and doesn't make sense regardless), which is not necessary and leads to all kinds of bad issues. Have custom code that needs to be compiled first, then need to have that code run? Cool, CMake can do that all in the same file and can automatically have those files run based on changes to dependent files, no need to have sketchy build scripts to handle that.

Additionally, why is it public? There's zero reason for an executable to have public depenencies of any sort. You can't link to an executable, it can't be a link-library dependency of another target. So how does it make sense for it to be public?

target_include_directories(protoTaskPlanner  PRIVATE
    $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/actual/path/to/files/>);

If you want to have generated code, you'll want to attach include directories to a target associated with a cmake side target which can run the command for generating that code. That's outside the scope of this answer, but there's multiple questions about this on Stack Overflow you can check out.

target_link_libraries(protoTaskPlanner  ${Boost_LIBRARIES} ssl crypto)

This will straight up not run. You need to specify PUBLIC/PRIVATE etc... here, also, you should not just do use a targets properties directly like this in target_link_libraries, boost exposes proper targets, use them.

target_link_libraries(protoTaskPlanner PRIVATE Boost::system Boost::charconv ssl crypto)

You also don't appear to actually be using what I assume would be the target associated with genericDictionary anywhere. If you're just using it to somehow get access to SSL and Crypto indirectly, that's horrible. Don't do that. Either actually use the dependency, or pull in the libraries through find_package If you actually need genericDictionary, and you need it's dependencies, target_link_libraries will automatically take care of that for you, and will list it's depenencies as dependencies for your target in the final build.

target_link_libraries(protoTaskPlanner PRIVATE Boost::system Boost::charconv genericDictionary)