Wayne joined the meeting and we did a couple hour work session together. He was showing me some stuff on the Google Workspace and email settings. We were going over SMTP, relay services, and app passwords. We changed the payment options for the Google Workspace account. We then flipped over to a number of other topics. Here are some of my other notes.

- We looked at session values and setting up both application and session values and variables on the server. We talked about a session object manager of sorts. This also includes the main adilas.biz website, shop (ecommerce), web (API sockets), and other public sites. We were thinking of having one session manager object and then passing in special flags based on what section(s) the user/client is using. It may vary or may include a number of different things, at the same time. We talked about sub classes within the session scope or session manager.

- Looking at SQL table joins and going over some options for inner joins, syntax, and converting our older code into different formats. Our goal is to make some of the joins tighter, yet still maintain the agile or flexible interface that we currently have. This is part of the datasource project (splitting up the databases and also being able to combine the databases, if needed).

- We talked a lot about UUID's and how this sometimes slows things down. As a thought, we may just use this (UUID's) on the payee/vendor tables. We spent some time talking about the global id numbers for payees (users and vendors). This lead to a discussion on off coding (altering our current code) to use a combo primary key vs a single auto generated primary key. We went over a number of scenarios and talked through things. We are putting the datasource project at $30K-$60K based on what we are seeing.

- We jumped backed more into session stuff and looking at errors that are undefined in session scope (variables that are used in heads and tops but don't exist in certain situations. We would like to create a master list of all session variables and what their defaults are. If we do this, we will be able to code against things better and really be able to push heavily on the know values. As a side note, we do have some pages that only create session values if a certain task or button is clicked. The code there will need to be changes to check for some other value (is it valid or not). If we do this, it should make our code more simple and more usable and more reliable. That will help.

- Consistency, and always setting things to a known state. Creating that central one-to-many type object.

- Dealing with session values, new rules, and new functions - we don't have to do everything in one swipe. We could do one variable, one page, one function at a time. Once we get it lined out (basically outlining the logic, flow, and template type mentality), we could hand it over to one of our other developers who likes to do processes over and over again. Basically, using our super skilled folk to build it out, then have our lower skilled folks help us push it to all pages and sections. We then would need to oversee things and delegate the tasks to our guys and gals.

Good meeting, making progress!