Merging and pushing up code with Eric. After the initial work, we spent some time talking about data modeling. Here are some of my notes.

- Eric would love to do some more data modeling and taking things into consideration and making a plan. He used to do this for other companies that he has worked with and for. Great resource. We could really use his help with adilas lite or fracture. This was like a mini database and data modeling lesson of sorts. I was loving it and scribbling down notes as quickly as I could. Fun stuff.

- We talked about flex grid tie-ins, flex attributes, and parent attributes. Basically, things that he sees that we do that might be built out into more efficient tools and features. Maybe rework some of this and/or combine some of the features.

- What really connects to other things (natural relationships) or what things are forced together (forced or special relationships)? We may want to look at use cases and try to pull out the natural relationships. Then build your application according to those natural relationships. You may still need to allow the forced or special relationships, but those become the edge cases vs the norm.

- If something happens over and over again, this should be part of the core system. Currently, we do use a lot of flex grid tie-ins to help with some of these special cases. As a side note, some of these one-off features are becoming more normal and should have their own logic and tables vs putting everything into the flex grid tie-ins. Great tool for getting things started but eventually, you may need to build out specific tables, logic, and pages. Make it more normalized and more efficient.

- As a note, what does the flex grid do? It allows for one-to-one connections, one-to-many connections, add log notes to anything, tying things together (main id's to sub id's or main id's to other main id's), and it also allows for up to 30 custom fields. Once again, it can be on a one-to-one basis or used and setup as a one-to-many relationship. Here is a help file that has more info on the flex grid tie-ins.

- As a note, the flex grid tie-ins have been the big brother to the things we are trying to build called flex attributes or real in-line database extensions or real in-line extensions for short. Here is a small, older graphic link, of what we are trying to do.

- We talked about the bus to motorcycle project (datasource project or world building project). We are headed to a new model where the corportion id numbers (corp_id) will be left out per database. Each company will have its own database and thus may not need the corp id number. This deals with table names, joins, and data that gets stored in the database.

- Back to the flex attributes and a possible option to build them right into the main entities or high level tables (for the 12 main players or wherever we see fit to put them). This option has some pros and cons. We'll have to work this out. Currently, I'm really leaning towards something similar to what we did for the current flex attributes or parent attributes. Let them build and setup any custom fields that they need. Dynamic relational model. Just for fun, here is the progression - flex grid tie-ins (2009), sub inventory attributes (2015), parent attributes (2016/2017), flex attributes (2020).

- Lots of talk about data modeling and being able to take off the corp_id. Including on the end of corp-specific tables - for example: invoices_53, invoice_payments_53, time_sub_inventory_53, and a slew of others.

- Maybe break the pili or po invoice line items into two different pieces. It was joined together to help with inventory counts over time and across multiple locations. Anyways, we may look at separating those tables into multiple pieces. Super important, make sure to remember and include locations. If just a single location, we could do the architecture differently. However, with multiple locations, it gets a little bit more complicated or tricky. There are tons of other possible options.

- The payee table should be broken up as well. Currently, if a person or entitiy is tied to an expense/receipt, a PO, an inventory item, it lives in the payee table. Payees consist of users, employees, vendors, and special customers that had to get paid out of the system (a copy and convert process). Anyways, we may want to break that table up into users, vendors, and special customers (something like that).

- We talked about a concept called "attribution" and data normalization levels. There are two main types of data models. You have the logical data model and the physical data model. Entities and entities have attributes. Eventually, those entities and attributes get translated into tables, columns, and fields in a database. Often, most attributes become their own database column or field.

- Attributes are different than types.

- We talked about fields like "flag_for_1099", "password", etc. Those are attributes for certain entities. However, does a vendor need a password field, most likely not. Each field or attribute needs to go with the entity that it belongs with. We, at adilas, tend to mix and blend some of the attributes between different entities. In some ways that is fine, but it requires explanations, instructions, and training. It's not as easy to follow without someone to guide you along. Anyways, some good conversations about data normalization stuff. What goes with what and why does it fit like that?

- Make the names readable and logical where possible. We do a pretty good job on that, but there is some randomness in there as well. Along with that, we jumped into talking about a section called special accounts. We are planning on using that for gift cards, loyalty points, in-store credit, vendor credits, punch cards, and other special account transactions where we almost need a bank account style with a rolling number and being able to add/subtract using individual transactions or actions. Anyways, we have a few fields in there called dev_flag_1, dev_flag_2, and dev_flag_3. We use those flexible fields to help with certain parts of the process. In a way, we didn't know what we were going to need, so we added in some flex fields. Well, now, those flex fields have rules and hold certain data that could be its own column or field. However, because we didn't know what would be needed, the fields are somewhat mixed, depending on what is stored there and what kind or type of transaction record is being stored (loyalty points vs gift cards or whatever).

- The conversion trickled over into human reference fields vs computer identifiers, ids, or computer reference fields. They are different and play different roles.

- As you think things out, eventually you have to transform or go through a transformation from logical models to physical models. Eric kept saying that we should be shooting for the third normal form (data modeling and database modeling). Figure out the whole business world (plan it out as best you can) and then build out what you need, based on what you see and/or know.

- We talked about aggregates and data warehousing. I mentioned that I would like to build out tables for yearly per location, quarterly per location, monthly per location, weekly per location, and daily per location. We would also have the underlying transactions or transactional database tables (raw data that holds all of the data). The other tables would be what we transform the transactions into (a form of aggregates or business intelligence).

- Along with aggregates, Eric was saying that sometimes you can watch the database and see what tables, queries, and reports cost the most (data, traffic, or processing time/energy/frequency). You then build out aggregates based on those findings and/or known needs. For us, we've been doing this for long enough, we know a few places that could really help with speed, server load, and provide great BI or business intelligence levels.

- Our system has to go clear out to the full accounting level. That changes how we do certain things. That is awesome! Our sort of end goal is perfect accounting, aggregates, per day, per location, and per category. Some of those (category levels) vary but they have mostly been defined in the current system. That is huge. We have a plan, we have a path. We just want to refine it. Eventually year over year reporting, monthly by month comparisons, real-time data - all data is live and searchable (adilas).

- Snapshots, aggregates, different preset and controlled data levels. We may need current data (tables without any dates - assumption of current counts, values, sums, totals, averages, maxes, mins, etc.) as well as dated or historical data (tables with dates to allow previous or prior lookups and date driven lookbacks).

- What about enterprise mappings and cross-corp stuff? We need to plan that out as well.

- We also need to consider servers, speed, reliability, backups, redundancies, and how deep we going?

- Lastly, Eric could help with a ground up data model. We could pick a topic, break it down, and do a number of smaller sessions vs a big push. That would be too much. Anyways, great meeting and Eric could be a great resource for planning, checking out our decisions, and planning out the best course of action. Good stuff!

Meeting with Bryan to push the flex attributes for PO's. The flex attributes allow for custom data endpoints per main group (12 main player groups). We currently only have flex attributes for customers, elements of time, and now PO's. Eventually, we want to add this same feature for each of the 12 main player groups. As a side note, originally, these flex attributes were going to be called real in-line database extensions and were going to be the big brother of the flex grid tie-ins. When we get everything out to the fracture level, we want to make sure that we have the flex attributes built out for each main player group. The main player groups are: Deposits, invoices, PO's, expense/receipts, balance sheet items, stock/units, customers, vendors, employee/users, parts/items, elements of time, and quotes.

Another thing that is really wanted, and we would like to build for fracture, is a granular level of both visibility and searchability. The clients want to be able to see everything and then be able to filter it down as well. That seems to be a reoccurring theme and request. Currently we have a number of prebuilt reports. That is great and all and needs to continue. However, to make it even better, we need to provide options on the advanced searches that show every field, every connection, allow for toggle on/off (show/hide) fields and columns, filters for each section, and options for both show and export. Once again, full visibility and full searchability. That's the goal. Adilas - all data is live and searchable.

Bryan and I got his code all merged in and pushed up to data 0 for testing.

Going over lots of requests for new and enhanced reports. Small errors and fixing a few things. Cory had a small list. Lots of talk about flex attributes and the need to build them out on all 12 main application player groups. Currently, we have them on customers and elements of time. It seems like the next one that is warming up is PO's. We have clients that are wanting to be able to add new and flexible data points to PO's (purchase orders). Of course, once they get added, they for sure want to be able to search by those new flex attributes. They also want them to show up on all the correct spots, forms, searches, reports, and exports. Not a problem, it just takes a goal and some time.

It seems that across the board, our users, on a global level, are wanting more and more control of their reports and exports. This inclues settings, preset and saved favorites, show/hide certain fields or columns, able to rename fields, set and remember the search criteria or filters, and be able to pull down any and all data (reports or exports).

Cory and I were talking about "visibility vs searchability". Our users want "visibility" first, then they want the "searchability". Basically, our users want to see the data and then be able to limit it and/or filter it down from the results that they got. From a coding side, it is easier to filter (control what will show) vs showing everything and then filtering after all of the data is shown and/or pushed out to the user (way more traffic, memory, and bandwidth). On the coding side, we would much rather have you know what you want, then we only have to serve up those records. Sort of a flip flop on who wants what and which way they approach their data and report results.

We have a report that the users want to control multiple parts of an object (say PO's or purchase orders) all from one export and/or report. Granted, the PO has multiple one-to-many relationships, table joins, and records that need to be matched up and presented. Imagine a report search page that has show/hide checkboxes for all of the main PO data (location, vendor, total amounts, PO types, dates, notes, ties to external invoices, etc. - 20 some fields). They then want all of the show/hide checkboxes to show/hide columns for all of the line item details (quantities, costs, prices, items, descriptions, etc. - tons of new fields - 60+ fields). Next, they want any sub inventory information (sub reference id numbers, barcodes, units of measure, special sub attributes, RFID tags, etc. - tons of other fields - another 15-20+ fields). Without going too crazy, they also want any new flex attributes (extra data points or in-line database extensions), parent attributes (inventory level controls for parent items), and other data. I didn't count, but it could be well over 100+ fields that they want to be able to pull, show/hide, filter, and organize. It gets into some advanced settings and big reports with lots of dynamic logic. Not that it is hard to do any of that, it just gets more difficult when you are mixing so many things or parts of the object together.

Cory wants us to start with the "visibility" of the data. As a side note, we may have to off load some of the processing for these bigger reports. I want to be careful about building on possible already tippy code or projects. We have to make sure that everything is stable. After this conversation, Cory and I lightly talked about budgets. We also looked over some code and did some quotes for clients. There are many challenges when trying to mix and bled and mix viewing with searching huge datasets.

Lastly, we talked about fair compensation. We are heavily underpaid and not showing our true value. That gets complicated as well. It's an interesting mix and an interesting game.

Steve, Cory, and I stayed on the Zoom session after Kelly left. We were talking about the evolving nature of software and how it seems like it keeps heading towards a form of AI (artificial intelligence). We were talking about developers, projects, and project management stuff. We really want to get that datasource project done (bus to motorcycles or world building project). We spent a lot of time talking about funding. We are pushing as hard as we can, we need some gas money. Big requirements and a tiny budget. It takes time and resources. Our product and our users keep evolving. Project management and quotes with Cory after Steve left.

- It may be good to do a pros and cons analysis of attributes - parent attributes, sub attributes, flex attributes, flex grid tie-ins, and other in-line database extensions. Speed, bulk, capabilities, searchability, show/hide on all or certain templates or views, etc. Where are we headed next or how can we tighten things up to make it even better?

- We first have to get the data into the database. They we have to be able to get it out. Next, what happens if anything changes? We need to think through all aspects of lifecycle of the data.

- We really need a plan - detailed out - commit to it - then really do it.

- More and more of a need for bulk tools (data coming in, data going out, and updating and changing things).

- Charging for what we are doing. We, as a company, are missing out.

- The value of our user/client base as a testing group. We couldn't pay for what they are doing.

- Cory and I were talking about requirements for industry specific software. Expectations of our clients. We have a standard package and then we customize on top of that. It's really tough to do everything, well.

Sean, Chuck, Cory, Shari O., and I were on a meeting. Shari O. came in a little bit later after the rest of us had started. The goal was to talk about and look at options for creating some industry specific tables and logic to hold bowling ball drilling specs (important pieces for the bowling industry). I was taking notes and the others were chiming in with questions, feedback, and ideas. Good little brainstorming meeting.

Here are a couple of topics of discussion:

- We have some really old screenshots of some bowling specific software that looks like it was developed in the 1980's or 1990's - looks like old windows stuff.

- Talking about options by using flex attributes - (real in-line database extensions). Those are fairly new and are unlimited, but they are only currently developed as a one-to-one relationship (you only get one set of unlimited data points) vs a one-to-many relationship where you could have one customer and they could have many balls or different drill patterns. We would also have to go in and setup these flex attributes per corporation. We went over some other pros and cons there.

- We could use flex grid tie-ins or even limited flex grid tie-ins, but we cap out at 30 custom fields. They can be used as one-to-many relationships and already have a ton of flexibility and features built in. Possible option.

- Currently, one of our bowling customers is using an old school paper type model. They print out a form, fill it in, and then scan and upload and attach it to a specific customer. They can upload as many new images as needed. They could also use PDF, Word docs, Excel files, etc. - using media/content vs photo uploads. These options exist right now at no additional cost, just some training. The downside here is that each photo or scan is not searchable. It exists but you can't search for patterns or combine things.

- We talked about a budget of between $2,000 and $4,000 ish to get a custom project up and running. This would include onsite research, planning, designing, development, and even some reporting. Just guessing without more info at this point.

- We have a number of resources (people in the bowling industry) that could help and guide us. That is huge. We just haven't really tapped into it yet.

- Chuck had some great questions about other service type industries and how they track their repairs and custom jobs - ski shops, bike shops, etc. Maybe look at what it would take to do and/or extend things out to other industries. Good insight.

We closed the meeting and both Cory and Sean are going to poke around with some of our contacts and see what we come up with. As it develops, we may setup other meetings to keep pushing the project forward.

Talking with Steve about limited flex grid, status, and where things are headed. He is excited to expose some of the new tools that we are developing out to the rest of our clients. We are also trying to stay ahead of Chuck and what pages he is redoing and making them look better. That lead us into some discussions on layout and display options such as tabs, accordions, pop-ups, modals, and other modern display and layout styles.

Everything keeps going back to settings. We talked about 4 different level of settings, that we are seeing. They are: 1. Corporation level settings (corp level or world level), 2. Group or player group level settings (12 main players), 3. Page level settings, and 4. User level settings. As a side note, settings are awesome, but they can also make things feel like it is more complicated. You have to play the game of iceberg vs huge mountain. Hide what you can, only show what is needed, but still make it available if needed (like tools in the shed). We see more and more of this type of thing coming as we build out toward fracture and future development.

Another fun thing that we talked about was page views. We happened to be on the time homepage and going over different page views of the same data, but how cool would it be if we could build out reports that show up in calendar view, timeslot view, grouped or aggregated views, or normal details and tabular data type formats. So many options, including charts, graphs, and other layout options. Not to mention, export or save custom report settings. All available, we just need to keep bringing it all together. More stuff for fracture.

The next subject was dealing with getters and setters and how those pieces are so dynamic. Some of our entries have 30-40 fields or choices. We don't want to have to submit all of those pieces, every time, for a simple update. Getters help you get the data in smaller pieces, as needed. Setters help you set or update the data in small bitesize pieces. For example, say you have 30 records of flex grid, each with a possible 40 columns. If you do the math, that one bulk edit page could have over 1,000 fields. What if only 2 pieces of data actually change? Using a simple setter allows you to only alter smaller pieces of the whole without having to carry the whole load. Efficiency!

As we were talking, we can see the value of using small teams to push on projects together. That could really help with resources and giving everybody a buddy to work with. Along those lines, here are some other projects that we may give to Bryan or a small team of developers. Flex attributes for all of the main players (used to be called in-line database extensions), vendor/payee logs (modeled after the customer log section but for vendor/payees), and other projects that already have a small handrail or guide. Anything that has been done before seems to be easier, due to the example or handrail for the developer to follow.

Steve and I touching base on different things happening over the weekend. Steve and Sean then jumped into some labels, custom invoices, and gram tracking options. Steve is really trying hard to build out more settings to help automate different pieces and processes.

John was showing us some of his work and progress on the discount engine. He gave us a small demo and showed us what is still remaining, things that still need some work.

The conversation switched over to getting things pushed up and out for testing and live usage. We are really trying to focus on doing lots of tiny or micro releases vs big huge releases. Along with this topic, we started talking about possible projects and helping out Wayne with some of his bigger projects. If anyone gets too big of a project, they tend to virtually stall out and lose some productivity. We talked about the datasource project (world building), flex attributes for other system player groups (in-line database extensions), and client facing scheduling stuff.

Steve and I doing a little bit of brainstorming. Mapping flex attributes out and how we could apply those flex attributes to specific time templates (or other templates - in general). We thought that maybe we could have a section, very similar to selecting money types for carts, invoices, expense/receipts, and deposits - allow the users to click and point and choose which flex attribute was applied to what template or list of templates. Basically, a flex attribute would be global for that main player group (12 main application players) and then you could limit it to show up and/or play with only certain templates.

Danny was saying "properties" or "characteristics" for flex attributes. The flex attributes are what we ended up calling the in-line database extensions. Flex attributes seemed to stick better (naming and wording).

Danny is adding some new email templates (5 new ones). Steve had me give Danny a small demo on what we were trying to do and get done for elements of time and new time settings. We also tied in how the flex attributes for elements of time would play into these changes as well.

Meeting with Steve McNew. We started out talking about volunteering and helping in our communities. Invest in the youth. Give, give, give. Good stuff.

He will be giving me some new white papers. Light touches to keep things together. Impact analysis, gather the small nuggets that we gain and find, and keep moving towards some more technical white papers. Steve also stated that he is willing to help us out with technical input and consulting, if we ever want to go in that direction.

After Steve McNew left, Steve Berkenkotter and I chatted over the GoToMeeting session. We can take our product out to custom levels, out of the box, better than some companies can do plain custom. We are built for that, in a way.

We talked about moving towards flex attributes (in-line database extensions) for employees and invoices. The employee stuff could be for HR (human resources) and other internal things. Invoices are so used in our system, allowing flex attributes to those would be huge. Once again, custom options right out the box. Build your own - whatever!

The shelf (code repository or code graveyard) - We would love to get some of the older projects off the shelf and make them part of the big picture (really deploy and launch them). We have some projects like: dynamic sales tax naming and new sales tax buckets, invoice due dates, save reports for stock/units, and tons of others. They are sadly, just sitting on a shelf, getting older and further and further away from the current master branch. It takes time and resources to get in there and revitalize those pieces and make them part of the bigger picture or part of the whole.

We would also love to make things as dynamic as possible from the get go. Build with that mentality in mind.

Bryan is already working on flex attributes for elements of time. This is where you can virtually extend the database and create your own custom fields and data points for elements of time. You can add data and details, show the data, and even search by those custom fields or in-line database extensions. Anyways, it looks like he is halfway through that process already.

Finished up this timeslot doing emails and light tech support.

Merging in code for Dustin and his bulk batch functionality for cultivation pages. Talking about ways of speeding up the deployment process and getting new clients and customers (corporations) up and going quicker and quicker. New systems and doing data imports. We talked about ways of getting things setup quickly and being more and more efficient. We then moved into QR codes and what they can and should do. We went a little deeper on this topic and went over some known uses of QR codes.

We then started talking about projects for Bryan. We would love him to start working on flex attributes for elements of time (in-line database extensions for time and time templates). We also talked about getting Bryan to help clean up the shelf (existing code that hasn't been fully tied in). We know we have projects like sales tax version 5 (v5) project, invoice due date project, and many others.

Steve and Cory were talking about inventory forecasting and usage pages. Watching and monitoring supply and demand of items and such. Inventory planning type functions and options.

Towards the end of the discussion, Steve and Cory were talking about independent reps and consultants and some pros and cons. We have had great results in the past, however, things are changing and we are on purpose trying to bring things more internally to provide those services from inside of adilas. This is a conscious effort. We will continue to work with a few select individuals, but all new accounts will be helped and supported from internal resources. That's the plan.

I've got a project coming up that needs some new settings for elements of time (calendar, scheduling, and events). I woke up this morning and couldn't stop thinking about some ideas for some new settings. I scribbled them down on a 3x5 card (front and back). I was saying a prayer and the ideas kept coming. Kinda fun. Also, the other fun thing was almost being able to see how to do some of these things and the potential that they could unlock. Really fun.

Anyways, here are the ideas. After I got them all scribbled down, I texted Steve to see if he would want to meet for a bit to go over the new settings and ideas. We jumped on a GoToMeeting session and he and I had a good 45 minute chat, with drawings, proposals, pitches, and lots of ideas going back and forth. Good session. Here is an expanded version of some of my little notes and scribbles.

- Dealing with time templates - what if we allowed for a basic mode and an advanced mode? Some people may not want to see all of the pieces. The basic mode would be what currently exits and/or something pared down from that. The new advanced mode would allow for all kinds of other settings, verbage changes, field name aliases, special instructions, sort order (where the fields show up), settings, required options, etc. The time templates page would have a toggle switch to go between the basic mode and the advanced mode. There would also be links directly to the advanced and basic modes from the list of time templates page. Same permission, just a toggle switch between the page modes. As a side note, Chuck recommended that we maybe have a "custom" mode.

- We already do this with customer database field names (allow for field names to be controlled). We want to do the same thing for elements of time. We will use the db_field_settings table to store specific info (field name options) for each time template, if the users wish to. If not, we will use a default set of data stored in the db_field_settings table for basic time_templates. We will use the field called db_table_name to store the value "time_templates" to store the default values assigned to corp 1. Just like the customers stuff. For each time template, we will change the name from "time_templates" to "time_templates_[555]" where the number will be the corp specific time template id number. Tons of sweet options there already. Aliases, defaults, placeholders, build your own drop-downs, required yes/no, max, min, show/hide, sort order, etc. As a side note, we currently let the main time templates handle the show/hide options. Somehow we may need to sync those up and/or figure out which one is the master. For right now, I'm still leaning on the time template being the master and the db_field_settings table holding the naming, aliases, special directions, defaults, etc. I hope that makes sense.

- On the advanced time search page. I would really like to add a master template switch at the top of the page. This would be a drop-down form field that shows all of the time templates. If a time template is selected (or preselected through a URL.template value), at the top, and submitted, then the page would be able to virtually slim down based on the settings, naming, and custom pieces per time template. The current advanced time search has everything plus the kitchen sink. If a template is selected, then the page could only show those pieces that are turned on, the correct naming, the correct filters and search criteria, and hide all unused sub searches as well. The time template settings would also affect the sub time searches and use the correct verbage, info, naming, show/hide, filters, etc. Basically, be able to dynamically convert the advanced time search page into a time template specific search form or page. That would be super cool. Also, if a template is selected, the search results could also translate and show the correct fields, verbage, settings, and make it feel round trip (search, results, and details). Higher in this entry, it is alluded to the fact that we could control the page with a URL value (URL.template) and then we could link to it, store quick buttons, etc. That would be really handy. As a side note, Chuck recommended that we look into a tab or tabs based page for all of the different searches - make it more digestible vs all in-line down the page. We could still have the template switch, but show the different searches in a vertical or horizontal tab display. Great idea.

- On the sub flags and tags, we need some more template settings. You can turn 5 different sections on with this sub (one of the bigger subs). A section within the sub tags and flags, was one that that was added later on (for phase tracking and location moving) it deals with possible sub tie-ins (PO's, invoices, quotes, etc.). Currently, we can't control that piece through settings. It just kinda got added out of necessity vs through the normal development process (planning). All we need to do is go in and add those settings, flip some of the old values (existing data) and make it more straight forward as people set those things up in the future. Along those same lines, the sub flags and tags may need some help on the output and display and the add/edit process. All of those pieces were altered and got the sub tie-in hardcoded to them. We may need to remove or make that more settings based.

- On sub flags and tags, I would like to be able to show the last flag or fag on the main. It holds the data right now, but doesn't show the entry. Light tweak to make it show up on the working with time page and the printable time page. Also, check the searchability of the last known flag or tag on the main, through the advanced search.

- There are two pieces of the main elements of time that we can't control via settings yet... they are the make private and admin only checkboxes. We need to be able to turn those two settings on and off. Currently, every element of time automatically gets those. They are not used that often and need to become settings so that we can show/hide those options. As a side note, those two settings do have some hardcoded text values like "private" or "admin only" that show up on other reports and report types if someone searches for something that is marked as private or admin only. Just a heads up. We may want to limit the verbage on these settings.

- The general amount field on the main elements of time is currently locked to showing dollars. I would love to add some settings to allow that field to be named and formatted. I was thinking of dollars and cents, decimals, plain (no formatting), and integers (remove the decimals). That would make it more useful. For example: I have a time template called mileage and I use the general amount field to hold the number of miles. It holds the correct value but when I pull the report, it always shows the miles in dollars and cents vs just a plain or decimal number. Anyways, I think that could help. Also, along those lines, there are some budget and estimate settings (different settings but still tied to the main element of time)  that could use similar number formatting options. See notes at the bottom for some other mileage ideas.

- What about allowing for the sort order of the fields? This is more complex, but it would be cool. You could put whatever makes sense to you first and move other fields around (up and down or sorted). We may have to circle back around to make sure this is possible.

- Recently we added a thing called flex attributes to the customer section or player group within the system. The flex attributes are virtually real in-line database extensions. We allow for new fields to be configured, added in, able to search, able to show-up, etc. These flex attributes are datatype specific (dates, times, strings, numbers, decimals) vs just plain text fields like the flex grid tie-ins. We eventually want to add these flex attributes to all 12 main system wide player groups (customers - already, invoices, quotes, parts and items, stock/units, elements of time - coming soon, I hope, employee/users, vendors, PO's, expense/receipts, deposits, and balance sheet items). One more thought on this topic of flex attributes. We may need some flex attributes on a global scale (able to cross time templates) and we may need time template specific flex attributes. We may want to do the global ones first, then limit or tighten things down for the time template specific flex attributes after the global flex attributes are added and stable.

- Horizontal grids - show time blocks with main categories or values going down the left and time across the top. We would love to allow for saving settings, allowing for special homepages, and custom buttons, just like my cart favorite buttons. See element of time 6967 for more info on horizontal grids. This is a form of blocking out times and who or what is scheduled, called for, or booked. Ideally, we want to be able to configure these horizontal and vertical time views, so that we could have and use more of them. That would be really cool. Once again, see element of time 6967 to get more details and information on horizontal grids. We used a custom horizontal time view for the Beaver Mountain Ski School. They have been using it for 5-6 years now. We would love to keep building off of that type of a model and make it even more configurable and savable without tons of custom code. Make it a tool for all of our users.

- Visual blocking of time... both horizontal and vertical blocking or showing bars or blocks of time. This is a visual way of showing what is booked and what is not booked or called for. Both directions, horizontal (side to side) and vertical (up and down). We need them both. We currently have the time slot view which is close to vertical blocking, but it still needs to be more bold and handle the blocking in a better way. The logic seems to be there, but it still needs a little visual help to really bock and virtually claim those slots or segments of time. It might be nice to ask for certain visual blocking right from the advanced time search - kinda like a report type. We already have a calendar view, time slot view, grouped view, and detailed view. Maybe add horizontal block view, and vertical block view. That would be cool.

- We would like to add in some dynamic dates. These special dates would allow reports to be saved with the dynamic dates vs a physical date range or custom fixed date rage. The dynamic dates would and could be things like: current day, current week, current month, current quarter, current year,  yesterday (prior day), last week, (prior week), last month (prior month), last quarter (prior quarter), last year (prior year), tomorrow (next day), next week (future week), next month (future month), next quarter (future quarter), next year (future year), etc. These would be really handy, so that saved reports could just pull relative info (based off of the current or today's date value), without having to worry about updating or flipping date ranges. Anyways, I think this will be awesome and we could use it all over the system on other reports and pages. Especially, wherever we are saving reports and pulling up saved data. These dynamic dates may make it super awesome and powerful.

- Be able to use the calendar view and calendar overlay for tons of new reports. Be able to save almost anything in an calendar type view. That would be awesome. Once again, the dynamic dates, mentioned above, would be really cool with this. Maybe even have an advanced search page that could save and filter the data and then show it on a calendar type report view. Great visual for what is happening on what day over time. We could call it the advanced calendar page or report. It would also be super cool if we could point subs of time to some sort of calendar type report or other visual time blocking type report. Currently, most of the subs only show up in detail view (normal tables with rows and columns). Being able to see the subs in other report formats (calendar, time slots, time blocking, horizontal, vertical, groups, etc.) would be sweet.

- On the template settings (techy stuff behind the scenes), currently, when adding and editing a main element of time, you have to pass in the template settings when adding or editing the main element of time. I would like to automate this process. It would make it easier for the developers. This is more of a behind the scenes switch on the methods and method calls. Most of those template settings don't change very often. We should have the methods themselves do the look-ups and make the changes (adds and updates to the fields on the elements of time table). This would really simplify the add and edit main elements of time processes.

- Being able to control the names and settings on the subs is going to be huge. This means what they are called (like sub dates and times, sub comments, sub sign-off's, sub flags and tags, sub payroll, etc.) and what fields they hold. Be able to change that on a per template basis. It also includes the sub fields and what they are called. For example: Say the default sub section is called "Sub Dates & Times". We may want to rename that "Amenities" or "Sub Bookings" or "Project Timecards". We could also control the field names with the sub section. Say the origianl or default field name is "Sub Title or Caption". Say you wanted to change it to "Extra Booking" or "Follow-up Reason" or "Sub Event" or whatever. Being able to change what the main things are called and also what the sub fields, within each sub of time are called and how they act. That will be a game changer. Here is a list of the current subs of time.

- On the working with time page, make the add/edit subs easier. Add in buttons to help with the add new process. The current way is just a simple link. It kind of gets hidden. Make it a little bit more bold and obvious.

- Some of these settings and concepts would be super cool for the fracture project. We really want to hide whatever we can, show what we need to, and allow for the whole thing to be dynamically (through data vs code) controlled and configured. That would be a super cool piece for fracture. See the above entries for some ideas.

- Futuristically, we would love to be able to switch elements of time between time templates. Currently, you get one time template and that is it. We don't allow an element of time to switch templates due to all of the background settings that are being held, monitored, and used.

- We may also need to add in some settings to deal with the general name for elements of time. That is very broad. Each time template can be named individually, but we have had clients that want it called the calendar, scheduling, etc. We may need some bigger corp-wide settings that control the main name and smaller abbreviations. For example: The defaults may be "Elements of Time" and "Time" for short. However, they could be set to Calendar, Lessons, Schedules, Reservations, Rentals, Bookings, Assignments, Tasks, To Do's, etc. The more that people can call it what they want, the less they end up fussing later on. That key piece of speaking their language is huge.

- It's not all code, some of this is just planning and dreaming

- It may be nice to use a spreadsheet to help with some of the planning. We have lots of rows, columns, and complex data that is needed for the planning portion.

- As a side note, it was so tempting to see a need, and then jump and try to fill that need. I on purpose spent some additional time (hours and hours), trying to get ideas and thoughts out of my head and on to paper (virtually) so that all of the pieces became public knowledge. My normal urge was to figure out a portion of it and then just do it vs writing all of these things down for the benefit of others (and myself).

///////

On 8/10/21 added some ideas for advanced job costing.

- Mini P&L per element of time. If we can tell that an invoice or expense or PO was tied to the element of time, have it automatically show up in a mini P&L (profit and loss) statement. This may be done with flex grid tie-ins right now (currently - but somewhat manual). We would love to automate it and build it into the mix. That would be really cool. Maybe do some searching for "job costing" to get other ideas.

///////

On 9/2/21 added some ideas from Chuck Swann

- Chuck read through these ideas and gave Brandon some feedback. Some of the ideas have been listed above with Chuck's name (search above). Here are some of the highlights - What about adding in some custom CSS (cascading style sheets) or custom display options? Maybe think about using a tabs based display for the advanced time search. The word or mode of "custom" may be better than "advanced" - technically, the advanced mode could be the custom mode, it just sounds better and more fitting to what we are really doing - dealing with time templates. Lots of the existing pages need an update to work better with the snow owl theme (style and face lift for pages). Make elements of time easier to use, in general.

///////

On 9/2/21 added ideas and projects from Cory

- Build out the online and customer facing scheduling options - this is a big project, all by itself. There are more details on other pages. We have a bike shuttle company that needs online scheduling (from ecommerce) and there are many others who are looking for this. Any business could use customer facing, online scheduling.

///////

On 8/21/23 added some ideas from a buddy - Josh Hanks

- On mileage. Maybe add a sub of a sub to do mileage. We may also need a standalone option (list way up higher using the general amount field) or adding it to a sub date and time entry. Not all entries would need mileage, thus a one to many off of the subs (sub off of sub dates and times). Imagine template settings under sub dates and times to say something like: Need mileage? If yes, do you want to enter a simple number (x number of miles) or use start/stop odometer readings (then we automate and do the math when submitted). Anyways, I had a great meeting with Josh Hanks on 8/21/23. He's a water master, ditches and irrigation stuff, he has a need for these things mixed together - projects, hours, notes, and mileage. The other benefits would be reports, exports, and math that is done for you. We may also add in photo galleries, document management stuff (media/content), etc. We have all of the pieces, we would just need to mix it together better and make it a small industry specific skin. Eventually, when we build out fracture or adilas lite, we want to include some industry specific skins as part of that project or platform (part of the value add-on core model). This may be a fun little venture into that world.

Meeting with Cory and Steve - Working on a super deep inventory report. Looking at aggregating quantities and counts, mins and maxes, reorder options, parent attributes, sub attributes, flex attributes (new), core values, build your own reports (point and click), save and name your own report, setting pages (defaults), template and builder processes, and in-line database extensions. Lots of fun topics.

We talked a lot about "core" attributes (existing database columns and fields - core attributes).

We also talked about building, using, and deleting small aggregation tables for current part quantities. Great little work session.

Looking over advanced customer search code with Bryan and trying to add in options for searching and showing customer flex attributes in the advanced search. In deep in the code. Multilevel arrays, loops, conditional logic, etc. It's all there. This is part of a project to get better search options for the flex attributes (in-line database extensions).

Cory jumped on and we worked on some ideas on reporting and reports based off of the flex attributes (in-line database extensions). We have them implemented for customers, but need to get deeper into being able to search, pull up reports, export, and being able to filter data and recordsets based off of the new flex attribute values.

We also talked about other projects such as aging payables and adding new layouts to mimic what we do for aged receivables. We got into custom wholesale taxes and being able to switch between normal taxes and certain excise taxes. It gets really complicated. We talked about switches, phases, and more complex tax settings.

The last project that we went over was dealing with bulk tools for ecommerce. Show/hide on the web, long web descriptions, specs, reviews, etc. Currently, most of the web or ecommerce settings, you have to do them one item at a time. We are getting more requests to be able to manage things in bulk on the ecommerce side.

Working with Bryan on flex attributes on the web and through ecommerce. These are custom (special database fields that are needed and added on a per corporation level) fields that get setup to collect extra or special data. You define them, name them, setup the defaults, require yes/no, and even build drop-down lists if needed. Unlimited custom fields. They only exist for customers (clients/patients) but we've prepped things to allow them to be used for all 12 of the main application players. This is part of the real in-line database extensions project. It is coming into being.

Meeting with Cory to go over projects. We were talking about developers, schedules, updates, and projects. We detailed out a couple of projects dealing with ecommerce. One was for a new setting to show/hide a customer photo gallery in ecommerce. Allowing customers to upload their own documents and pictures. The other one was dealing with flex attributes and being able show and use those new customer flex attributes out in ecommerce (in-line database extensions). It is fun to see how each section gets built, and then a little bit later on, it gets refined and added to. It just keeps going. Constant refinements and progress.

Bryan circled back around and helped me launch round one of the flex attributes. It is only tied out to customers right now, but that is the first round of what we have done. The new code was pushed up to all servers.

As we keep going, eventually, we want to expose and release flex attributes for all of the main 12 players inside of the system. Some of the main 12 players are things like: customers, invoices, deposits, expense/receipts, vendor, users, parts and general inventory items, stock/units, quotes, elements of time, balance sheet items, and PO's. Exciting. This is part of a bigger project called real in-line database extensions. Step one is up and live as of today.

Work session with Bryan. We spent quite a bit of time going over the flex attributes project. We were doing some planning, scenarios, research, and discovery type things. We ended up talking a lot about the concept of try storming and being willing to circle back around. The flex attributes project is a cross between four different projects. It has takes us quite a while to get to this point. We are mixing and blending flex grid tie-ins, sub inventory attributes, parent attributes, and custom field names and defaults. When you mix all 4 of those older projects, you get flex attributes. These are what we are doing and going to use for the real in-line database extensions and options. Pretty cool. This is a big project and may take some iterations and looping (on purpose circling back around) to get it done.

Bryan did record some of the meeting and he made some notes dealing with datatypes and other requirements.

Bryan and I met and went over the flex attributes project. He recorded a few different segments. We talked about what we have already got by way of other applications that have similar concepts. We also went over some planning and details. Here are some random notes - no particular order.

- Flex grid tie-ins already have 30 custom fields. They are already built out to play with and handle all 12 main application player groups. Flex grid is pretty cool but it lacks data types and it has grown to be pretty large. All of the custom fields are text or varchar characters vs real data types.

- We are looking for a cross and a hybrid between the power of the flex grid, the dynamics of sub inventory attributes, and make these new real in-line database extensions play throughout the entire application. Cool concept.

- Here are some pages that already have similar type code - places where we could harvest some ideas and code: All of these are in the top_secret/secure folder.
-- sub_inventory_template_home.cfm - Lists out all of the sub inventory attributes per part category. We would want to do something similar but for all 12 main player groups.
-- sub_inventory_templates.cfm - Add/edit page that deals with sub inventory attributes. Our would be for all 12 main player groups.
-- add_edit_flex_titles.cfm - This page lists all 12 main player groups, uses settings and custom naming, and also checks for permissions. We would love to mix this page with the lists from the sub_inventory_template_home.cfm page. Nice hybrid.
-- edit_sub_part.cfm - This page dynamically builds form fields for sub inventory attributes. Eventually, we will need something similar for all 12 main player groups.
-- sub_inventory_view.cfm - This page dynamically shows any extras or sub inventory attributes without the edit capability options.

- Existing tables to look at are: sub_inventory_attributes, app_types, custom_text, custom_numerics, custom_dates, custom_json, parent_attributes.

- As we were talking... we are thinking of a couple new tables... just ideas. One would be called flex_attributes and the other would be called flex_attribute_data - the data table would allow for text, numeric, and date values. Somewhat of a combo table as compared to custom_text, custom_numerics, and custom_dates tables.

- We asked some questions... shared tables or corp-specific tables? Auto populate and build or just in time? New tables vs old tables (add or modify existing)? Think of the number of servers, number of corps per servers, developer instances, etc. All of these deal with scope, maxes, mins, pros, and cons. Design decisions. As a fun side note, I challenged Bryan to spend a couple of hours and plan things out. I also challenged him to use Excel (spreadsheets) and do some mock-up data and get a feel for things that way before any code is written.

- We also talked about the database field settings project vs these real in-line database extensions and flex attributes project. The database fields settings is somewhat similar in the fact that you get to name, sort, add descriptions, create your own aliases, show/hide things, etc. The main difference is, the database field settings are already tied to real live database columns and fields. For example: Say in customer you have a field called terms. You could rename it, require it, and then search it. Even though you did all of that, the database still calls it "terms" as the actual field name. The real in-line database extensions or flex attributes creates a brand new field and gives it an id number. No matter what you call it, all of the new data is tied to that id number with whatever you want to call it. If you want to kill it, you can. It is not really part of the original table. Anyways, we went through some small differences between those projects.

- Lots of drawing and building out samples. One of the topics was special dev flags or special fields just for developers to use - (dev = developer). We talked about how dynamic this table will end up being. We may want to build in some special fields that allow us to flag and tag the data as needed. Basically, thinking beyond our current project to where it will be going.

All in all, a great session. I'm excited to see what Bryan comes up with. As a small side note, we may need to provide an instructions field for flex attributes, we may also need a flag to show/hide on the web. Very similar to the database field settings. I hope we keep building and learning from our current prototypes and experiments. That makes it fun.

Going over projects with Bryan. He is working on two projects, somewhat related, but slightly different. One is the show on the web version for the dynamic customer field name settings. The settings are used internal to the system for the normal add/edit customer pages. Basically, the user gets to say show/hide, rename, sort, require, and add any custom verbage and/or instructions. Well, it turns out that they, our users, want the same things to be populated clear out to the web/shop (ecommerce) interface. This subject/project is extending those settings out to the ecommerce or customer facing pages.

Along with the new show on the web settings for the customer field names and defaults, we also need to setup some new defaults for the show/hide on the web portion. If we just add a new table column or field, it doesn't know how to play. We have to go backwards and update all of the pieces that have already gone under the bridge (older data and settings) in order to show every field out in the shop or ecommerce realm.

The other project that Bryan is getting ready to work on is called flex attributes. I sent him a couple of links to help him look up some more info on the subjects. Here are the two research links that I sent him.

Research dealing with flex attributes and research dealing with real in-line database extensions.

Bryan and I met for awhile. Then we brought in Steve to help us make some decisions. Eventually, we want to get things (inside the system) to allow for what we are calling flex attributes (real in-line database extensions) for each of the 12 main player groups. We really want that, but it is still down the road a bit.

Currently, we are using special flex grid fields and columns to get people going with minimal effort on certain projects. We also talked about single one-off type projects, custom black box code, and moving solutions into a more global or custom code on a bigger scale. Each one has its place and respective challenges. Having said that... there is a huge difference between doing custom code for a single client and taking that code out to a bigger audience and doing it for mass production. Often they have different approaches and can be tricky at times.

Steve, Dustin, and Danny were on the morning meeting. Eric popped in for a bit but then bailed out. Steve had some questions about loops and doing cross corp mapping on banks for some of his aggregated stuff. Dustin had some questions about large amounts of text and how to help tie-in custom in-line database extensions for invoices. For example: long winded delivery directions or some other long (over 255 characters) string or value. We talked about using the custom_json table as an extension to help with the longer notes for invoices. We went over some of the details and how that would work and/or play through.

After that, Steve and I jumped back on his cross corp bank mapping stuff. Bryan Dayton joined the meeting and we got him squared away with a BioTrack API/integration project. 

Both Eric and Wayne popped in. The main topic was going to be going over a new feature called flex attributes (similar to sub inventory or parent attributes, but for all of the main 12 players inside of adilas). However, we started in and both Wayne and Eric were pushing us to go in a more normal, standard, or data normalization type approach. We still may end up coming back to the flex attributes, but for this project, we can do it without getting super deep into the flex attributes and full on in-line database extensions.

Very interesting... there is a progression of how things get developed and how things progress. Some of the guys are trying to help us take smaller bites and bring quick value that gets finished quicker and allows for frequent deliveries that build on the prior pieces. Sometimes we dive deep and take everybody else with us.

There were a bunch of guys on this morning with Steve when I got on the meeting. They were chatting and helping each other out with questions and responses. Good stuff. Eventually, Eric, Steve, and I were the only ones left on the meeting. We spent the rest of the meeting talking about sub attributes for customers and how that would look. Lots of talk about real in-line database extensions and how those might be able to play in to the mix.

For a current project, we pitched and threw around 3 different proposals. Option 1 was to leave the core customers table alone and add a new wholesale customers table with options and settings. Option 2 was to expand the main core customers table with some new columns to hold the data. Option 3 was to build out "flex attributes" (aka real in-line database extensions for customers. This would allow our users to add whatever fields they needed to customer with specific data types (text, drop-downs, numerics, decimals, or dates). Great conversation.

Eric, Steve, and I spent a bunch of time writing down ideas, notes, and drawing diagrams of how things would look and/or function. I will attached our notes from the meeting, but the main thing was dealing with how to create a super generic table to hold the sub or flex attributes for customers, PO's, invoices, expense/receipts, elements of time, users, vendor, stock/units, etc. All of the 12 main system players.

Lots of talks about core values vs the new dynamic flex attributes. We also talked about auto creation, auto setup, and mapping to help make these new values work. Exciting stuff.

Project planning and coordination with Cory and Steve. On a big scale, we are seeing lots of interacting and connected settings starting to popup. That is both good and bad. Good in that people can set what they want. Bad in that they then have to be educated on what choices to make. Growing pains in the world of settings, configuration, and permissions.

- Talking about sub inventory and new package management settings and rules to play by. Auto open new packages, auto close 0 quantity packages, and other open/close type settings or rules.

- We have a client that needs really high numbers for invoices, invoice payments, invoice line items, PO's, and other places in the system. We talked about options to expand our current database tables or maybe go more along the lines of real in-line extensions and what that might do or handle. Imagine if we could flag a certain invoice that it has super high numbers. We could then use a custom table, such as custom_big_numerics, to hold the numbers in. We could set up the system to check for really big numbers and then run accordingly. Lots of talk about flagging and tagging records, and then rolling over to real in-line extensions to help handle the special cases. Think database extensions vs fixing the whole system to handle the random couple that exceed the norm. Some good ideas there.

- Along the lines of huge numbers. We may also want to include huge positive numbers, huge negative numbers, and huge numbers of decimals (details after the decimals).

Bryan and I talked about ways of using the real in-line database extensions in real life. He was to the query point and trying to figure out how to add/edit and filter by the extensions. We talked about options. We talked about using queries of queries, adding columns after the fact to the main queries, adding in aliases (with the correct data type) before hand, and even using functions like QueryAddColumn, QueryAddRow, QuerySetCell, etc. that already exist in Adobe ColdFusion. Lots of drawing and talking about options and funneling things down to usable values.

Bryan and I pushed up some new code. We did two small projects (merge and push) and then talked about a new project. Bryan would like to use the custom numerics table to do some real in-line database extensions. He has done a couple projects like this, using the custom tables and tying them in as needed. This particular project deals with a company that needs a 3rd salesperson (user/employee) added to the invoices. We talked about how to do that via black box code and using the custom tables (text, numeric, dates, json) as the extensions. It's fun to see them being used. More solutions to come.

https://data0.adilas.biz/top_secret/developers_notebook_home.cfm?q=real%20in%2Dline%20database&sort=asc - research on real in-line database extensions

Talking with Steve and Dustin about real in-line database extensions and using custom tables to virtually extend certain tables. We also talked about cross corp mappings and doing bulk processes.

Bryan and I pushed up some new code and some custom reports. We then spent the rest of the session talking about ways to virtually extend the functionality for clients. We went over some of the existing pieces such as black box code, flex grid tie-ins, parent attributes, sub attributes, web page settings (JSON or object storage), and then we settled on real in-line database extensions.

We did a lot of drawing and talked about how we could virtually extend any table without hurting any other corporation (super light and non intrusive). This concept allows us to virtually use the custom tables (custom_numeric, custom_text, custom_dates, custom_json) and create new add-on columns for almost any database table. I showed Bryan how easy it was and we even when through some mock-ups (text and drawings based on scenarios). The nice things about these custom tables is that the data could be a specific data type (a real number, a real date, a real string/characters, or a JSON object). Plus the tables are much smaller than normal flex grid tie-in records.

Here is some older research on custom extensions, real in-line database extensions, and custom columns on a per table basis. Aka - the big brother of the flex grid tie-ins.
https://data0.adilas.biz/top_secret/developers_notebook_home.cfm?sort=asc&q=in%2Dline%20database%2Bdatabase%20extension

Steve was talking about getting a designer to help us with the Bear 100. He would like to take it out to Google maps, GPS, mobile friendly, and even allow for people to use our site to do sign-ups and other pieces. We could have the site tied out to ecommerce and allow for tons of other options. That could be fun.

Eric came into the meeting and had a couple of questions about customizing the invoice and quote process. We talked about parent inventory, sub inventory, parent attributes, flex grid tie-ins, and even black box custom tables. We also talked about adding in some blank or generic flex fields in the quote line items and the invoice line items. They want some custom fields per line item. Steve was saying, don't tell me what you want... show me. That way we know what tool to use and where to put it into play. Steve was also talking about maybe going up steam and setting those moving variables up higher on the customer level. In a way, the over arching question was I want to extend the existing options and functions per invoice and quote line item. We then have to help, how do we figure that out and what solution could we use to solve that problem? Good stuff.

This doesn't play in quite yet, but at some point we would love to get into real in-line database extensions. That is somewhat of the bigger brother to the flex grid tie-ins. Being able to add and subtract data points and data fields per section. As a side note, we have tons of companies that virtually commandeer (take over - like a pirate ship) any field that they can to get the job and/or task at hand done or finished. Kinda interesting.

Steve wants to get more information, from the source. He would like to get a real world scenario and then make a plan from there. Not just a quick band-aid, he wants to help develop the solution. What are the processes, what are the needs, what already exists, and what else is still needed? It keeps getting deeper and deeper (4 and 5 levels deep).

There was an analogy of a "part changer" - think of mechanic that just swaps out part after part in order to fix something. We really need the mechanic that gets in there and looks at the problem and then makes a decision. From Steve - It's not how fast you go, it's how well you go fast - older Porche commercial.

///////////////////////////////////

Switching gears, we started talking with Wayne about servers.

We were talking about virtual machines, physical servers, load balancing, and the difference between hardware problems and software problems. We were talking about clusters and getting redundancy and depth of options. If we stay with Newtek, we need to build in some of our own pieces. If we go more with AWS, we get to just use some the existing pieces. There is a trade off - AWS has more options but it also a deeper pool. Newtek is not as deep, but in some ways easier. We were also talking about rollover, fail safe modes, mirrors, etc.

We spent quite a bit of time talking about the Adobe ColdFusion engine and how we could potentially configure cluster type environment. When you get out of a single machine environment, what do you do with the database. On a single machine (server or dedicated box), it is simple. On a cluster, you have to keep things moved and/or separated. We would love to break some of the system down into their own databases. The idea here is making each database corporation specific vs server (whole box) specific. We have talked about this for years (since 2012 ish) and have called it world building and other project names. We really want to do this, but we also know that we have tons of code changes that are needed. We could separate out the shared tables in the existing database schema but we would have to do it table by table. As a side note, we have already done this very process for invoices, invoice payments, po/invoice line items, customer queues, sub inventory, etc.

One solution would be to create a corporation specific datasource (pointer to a specific database) and then help that get migrated and pushed around. We also talked about loading in objects per user that has all of their corporation specific settings and values. Eventually, we will still need to break out the payee/users so that we have a master list and then allow them to be merged and virtually bridged to any corporation and even any system. We still have all kinds of exceptions, such as be in corp x but pretend like you are in corp y (look and feel and settings). It gets kinda crazy.

The subject started to switch to more and more object oriented programming, storing values in session objects, and other objects that are server based. We also talked about database server clustering and moving all databases (per corporation) to a dedicated database cluster that only served up data and content. Lots of possible configurations and options. Both Alan and Wayne were talking about cross-schema queries and all kinds of advanced things. As another side to this equation, we are seeing more and more of a need for aggregated totals, auto processing, daily task management, etc. All of these things play into the mix. We are seeing certain tables that are great as shared tables and other tables that really need to be independent and corporation specific.

As we move forward, even towards a fracture type model, we will need to separate databases, logic, move more towards object oriented programming, API socket calls, etc. Just for fun, Wayne and Alan were talking about different levels and using bigger teams - backend guys, database guys, middleware guys, frontend and UI (user interface) guys, etc. We aren't that big.

Steve's idea... Alan, Steve, Dustin, and Brandon are all going to be at a convention. Let's use that time to do some planning and take it to the next level. That's a great idea.

Worked most of the day on Friday - working on this report. I stated at 7 am and worked most of the day until 8:30 pm. I had a lunch break and went to the city party with my kids for a bit, but most of the day was spent on this report and logic. See elements of time # 4919 in the shop for more details. Lots of testing, rewriting, and some praying. This was pretty deep but somewhat developed into a series of smaller funnels and grouping and filtering to get to smaller and smaller data sets. Minimal trips to the database and then back and forth between memory objects to filter the data. It's not all the way done yet, and it has only been tested locally, but I feel that it has some potential, not just for the current report, but also for a future database feature called real in-line extensions.

The crux deals with a record set and then being able to filter that record set based off of numerous (unlimited) outside filters with somewhat randomly connected data points. The random data points, in this instance called sub inventory attributes, are user controlled fields. These custom fields point to custom tables that are not part of the main database tables. They basically hold the custom data and allow for the full structure to be reconstructed on the fly. We have future plans to use similar custom tables to hold data type specific values for all other areas of the database.

We have a thing called flex grid tie-ins and they now have 30 custom fields. Those fields may be named and used as needed. The main problem deals with a thing called a data type. The different data types are (generally speaking): text values, dates, times, numeric values, decimals, and on/off switches called toggles. We also have custom bulk object for storing JSON objects. Anyways, the data types allow for special things. The older flex grid tie-ins (all 30 of the custom fields) are strings and may hold all kinds of data. However, when being looked up and/or filtered, they are all treated as strings (simple text values). That makes it hard to do things like find something between this and that value, add things up, figure out max and mins, average, etc. A data type is required for that types of action. Anyways, lots of work was spent today on trying to work around those pieces and params. Good stuff.

The only other notes for this entry are some hints: joins, filters, and groups or grouping - doing these things over and over again, helped us get back to the requested and filtered data. Repeat the process as many times as needed. Keep narrowing the players.

Working with Bryan to cover some options for a client. The client wants to be able to record more information on a per PO basis. We talked about 4 different options. 1. Use flex grid tie-ins and black box code to get the job done. 2. Add more flex grid tie-in fields. Currently there are 15 and there has been some talk about extending that to 30 (double). 3. Use a custom form to collect the data, a custom action page to push the data where it needs to go, and build a custom black box database table specific to the task at hand. 4. Look into and build out the real in-line database extensions (be able to expand the native database tables as needed based on a per corporation basis).

We spent quite a bit of time discussing each option. Without trying, we ended up spending more time talking about the option 4, real in-line database extensions. See the link below for more notes about this option. We already have a few small in-roads to this solution, it just needs to go out the next level. As part of that conversation, we talked about a new table to help control the custom field names and assignments. This would be a new table that would allow us to setup the new fields, what to call them, what data types they were, and where the data would be stored. Along with this, we also briefly talked about the existing custom dates, custom numeric, custom text, and custom json tables. Currently, we already have some logic in place on sub inventory and sub attributes as well as parent attributes. Both sections use the custom tables to hold the data.

I warned Bryan that even though these new dynamic features sound awesome, there are some major challenges. Including searching, dynamic show/hide, requirements, sorting, defaults, custom instructions/directions, ect. In a way, it almost sounds like another project that is tied to a database table called db_field_settings. That table allows for normal or default database fields to be named, show/hide, sorted, defaults, maxes, mins, etc. They both have a similar flavor. The main difference is one controls tables that already exists and have fixed columns or field names and the other is kinda managing vaporware or fields that are wanted and needed but only exist in the real in-line extensions. Interesting.

https://data0.adilas.biz/top_secret/developers_notebook_home.cfm?q=database%20extensions%2Breal%20in%2Dline

At some point, we want to circle back around and rebuild a bunch of the pieces and how they act and interact. We would like to call this new rebuild "fracture" or something to that effect. Anyways, here are some brainstorming ideas on the fracture pieces that we would like to sew together. No specific order:

- object oriented approach (objects and data over time)

- use teams and different talent pools

- ice berg vs mountain type analogy (what is being exposed and what are the perceptions - visual exposure)

- settings and different setting levels (corp, group, page, user)

- subs... of sub (everything is fracturing into smaller and smaller pieces) - plan for it and embrace it

- API socket connections and external work flow options

- database scaling (corp-specific databases or corp-specific database tables)

- real in-line database extensions (add/edit/remove database fields and help them flow through the whole system)

- 3D world building - keep going and building out these ideas and concepts - one step at a time

- data assembly line(s) - concepts of tracking phases, grouping, sub locations, allowing flex and checkpoints, permissions, mapping to financials, etc.

- using time or elements of time as a base level and then mix, blend, and share sub functionality and tracking options (more objects and data over time stuff)

- funding and making sure we can fund the planning, design, and development of our game plan

- help files, videos, and SOP (standard operating procedures) - standard and custom

- black box and ways to customize the pages, verbage, logic, and process flow

- summarized data (aggregated data) vs transactional data (all the steps and transactions) - we need both - watchers, feeders, and triggers

- following and dreaming the dream - it may sound way out there... but following that dream is huge

- make a visual plan

- include general testing, unit testing, validation (local and serer-side), and standardizing requirements

- version control and deployment

- going back and doing research and review of older notes - tons of mini gold nuggets to harvest from doing this over the years (make sure and harvest some of our own ideas)

- use of sub homepages and graphical hubs of sort - also use graphics, charts, graphs, and other elements

- summed up data with drill-downs or searches available (basic or advanced) - approach all most everything from a summed up version into a more expansive (expanded) view and/or format

- be able to export any data to CSV, Excel, PDF, and general web format

- smaller mini functions - getters and setters - for miniature database access and updates

- use sub flags, tags, and other similar features - lots of ideas about sub phases, sub groups, sub locations, sub flags, sub tags, sub progress, etc. Lots of prior documentation on elements of time and subs of time, including how to virtually adopt functionality between main player groups (invoices, deposits, expense/receipts, PO's, customers, parts/items, stock/units, vendors, employee/users, quotes, elements of time, balance sheet items, etc.)

- custom look and feel - able to match moving trends

- responsive (able to change size and layout based on device or screen size) - mobile development

- sales - how are we going to market and/or sell our products and services - how are we going to set things up for correct billing and tracking (usage, storage, bandwidth, queries, connections, data, files, images, etc.)

- communications, push/pull notifications, automated things, queues and scheduling tasks, bulk and individual communications

- good project management

- sub permissions - almost down to the function type level (as needed)

- dynamic verbage, custom layout(s), dynamic link builder (favorites), and simple look and feel

If you are looking for other ideas for the fracture account stuff. See this URL or web address: https://data0.adilas.biz/top_secret/developers_notebook_home.cfm?q=fracture

Bryan and I were going over options to expand the flex grid. We currently have 15 custom fields. We have a client that wants us to double that and go to 30 custom fields. We talked about it and came up with 3 possible options. They are:

1. Expand the current flex grid to allow for a total of 30 custom fields. We also talked about possible JSON (object level) storage within the flex grid tie-ins.

2. We build it out similar to sub inventory attributes and parent attributes - with custom columns, data types, and make it unlimited. This is kinda along the line of real in-line database extensions. This would be super cool, but caries a higher price tag. The benefits are real data types (numeric, dates, text, toggle/boolean values, etc.) and also fully unlimited.

3. The other option is a custom black box database table to help them specifically get what they want and what they need. This one takes a little bit more consulting and time with the client, but may end up being the best solution.

We took some time and put some light price tags on each solution. We also talked about how each one would be rolled out. Bryan is going to check with the rep and client and see which one they would like to do. Once we know, we'll circle back around and do more planning.

The last item of the session was looking at the sub inventory sales and invoice report. We had a request to help with a timeout error that was occurring. We looked at the page and upped the timeout option. Really, that page needs some loving to really make it hum and run super fast. That will have to be another day.

Steve and Dustin were on the morning meeting. Steve had a quick question about a custom report for owners. We talked about some security hashes that could help the report be more secure. The admin report needs to be outside the secured environment and kinda a quick access link to a quick breakdown report for admin users. Steve has the report built, he is just adding some security and then going to add an access point from inside the secured environment.

I got a call from Russell. We talked for quite a bit about some custom client needs and how best to proceed with those requests. We also spent some time talking about using Bridgerland or BTech to help build out some of the fracture type pieces. The term "Fracture" comes from an idea that Steve had back in June of 2017. Everything in adilas seems to be fracturing and breaking into smaller and smaller pieces. Just discussions at this point, but basically a centralized brain (backend engine) and then a deployable front end that could be hosted on any client server or through a commercial web host. No special setup and a fully customizable frontend interface. The whole thing would talk and/or communicate through API socket connections and back and forth API traffic. We talked about ideas, options, etc.

If I were to put together a small fracture tick list, it would be something like this: (just ideas)

- Customizable look and feel (corp-level, department level, user level, and whatever in between)

- Preset defaults with ability to tweak out the defaults and settings (good starting spot and/or basic structure - starting templates)

- Permissioned out and/or micro permissioned (down to the functions per section)

- Settings for layout, settings for display (show/hide, sort order, aliases, instructions, required yes/no, validation rules, etc.) - As of right now, we are seeing settings on 4 different levels. They are world (corporation or business entity), groups or system player level (customers, invoices, deposits, expense/receipts, PO's, parts/items, vendors, users, stock/units, balance sheet items, quotes, elements of time, etc.), page level settings (what will show/hide, sort order, placement, flow, etc.), and finally, user level settings and defaults. How do I want to play the game (at a personal level)?

- Existing structure and flow, but it could be modified. Basically, a template of the starting procedure and/or process but make it able to be modular (build mini data assembly line type options per procedure/task). Think of our model with the mini bubbles and/or pods. These interface with flow, permissions, time, flex, and mapping clear out to the accounting levels.

- Real in-line database extensions. This allows us to provide a basic starting point (database tables and template flow) but also allows for things to be expanded and/or contracted (lessened) based off of configuration. These database extensions could be data types and allow for numeric, decimals, text, dates, on/off toggles, and even long text or JSON storage.

- Be able to save and build any kinda of report or data export - using existing tools

- graphics, charts, graphs, and other summary type options

- Support of both transactional data (what happens day to day) as well as aggregated (summed or pre-calculated values)

- Digital story telling, using characters, relationships, cause/effect choices, consequences, etc. World building concepts.

- Configurable interfaces and functionality per business vertical - click of button to switch layouts and/or processes.

- Customizable (data or logic hooks or black box technology) on client side, server side, and display and logic sides.

- Responsive and/or mobile ready

- Tons of flags, tags, and special callouts

- Be able to tie everything to time or elements of time. This could allow for groups, categories, types, sub locations, sub phases, sub status, etc.

- The list goes on... Most of the ideas have been recorded somewhere in the adilas developer's notebook pages. A great resource, it just may take some time to review and categorize. 

----------------------------------------

Back to other topics, Eric popped in and we made a few more notes and decisions on the sub special account tracking stuff (gift cards, loyalty points, in-store credit, etc.). After that, Wayne jumped on and we talked a little bit about email servers and what is needed there. I spent the rest of the time recording notes and reviewing to do lists. Busy times.

On the morning meeting with Steve. As we were going through emails, we had more requests for custom homepages and even some users wanting to go back to the classic invoice homepage vs the newer graphical invoice homepage. We then started talking about all of the different levels of custom...

We went into corp-wide settings, group settings (12 main player groups), page level settings (page control - how does it look and what does it contains and how does it work), and clear down to personal settings.  That got us into a small talk and conversation about an adilas "fracture" account. This is a concept of breaking everything down into mini pieces that could be stringed and/or put together in any combination. This could include pre-sets, pre-built options, special skinning, etc. It could also get into real in-line database extensions, themes, core black box options, etc.

What we are really selling is... We have tons of things pre-built and have a viable solution that has tons of functionality. This is ready and out of the box. We then offer people the chance to build their own application and virtually extend the functionality to what they really want. Basically, Steve was talking on a sales level, and was thinking about having a number of checkboxes... when meeting with a company, you could virtually check the boxes of what we have, we could also allow them to then pick and choose what they want to add on. Basically, we, as adilas, could tweak out our own product and create all kind of custom wire jobs.

We need to apply our own client filters and see who wants to play. We don't want to get over our heads, but we have a great number of guys who can do and handle certain pieces. We have a solution that is usable, right out of the box. We also have a platform that is customizable and moldable (like clay). Steve was also talking about selective selling and really selling our model vs just the system. Not everybody is a fit for what we do and/or offer.

Idea from Steve... Run the system for 6 months and get good at the system. Then come back and tell us what you want to tweak out and/or change.

People want major functionality... however, they also want it to look a certain way (how pretty is it), they also want a level of control (what can they tweak and change).

Function, form, and control - Alan was mentioning the word "Control" - that gets clear down into that fracture type level. We could have preset templates, show/hide settings, toggle on/off settings, permissions and sub permissions, main pieces, sub pieces, and even show/hide of the different modules. Currently, we have everything available... we may actually want to look at module level controls. For example: do you use payroll? do you use stock/units? do you use x or y?

Idea from Alan... What if we did some testing on new users and had them do certain tasks. We then see how intuitive the process are. This would be a refining process and then work from there. As a side note, we have been adding on for years and years. That is our current model. Maybe we need to rework our inter core and make it more module based and then be able to show/hide and/or be able to toggle things (full sections and/or pieces) to an on/off level.

We also talked about packaging and limited packaging of the system... For example: The limited package, the standard package, the deluxe package, and the mother load... package. Not sure what to call things... but it could be really cool. Basically, it all exists, we just show it (smoke and mirrors) in certain ways. Based on the package style and/or level, we could show/hide other pieces and/or features. Another analogy is a race car engine and then we offer the body styles like cars, motorcycles, vans, trucks, semi trucks, or even UFO's (see attached for an older image).

Adilas has a lot to offer... but what if I only need it for this or that? It sometimes feels like taking an army tank out to hunt birds, say something like pheasant hunting or duck hunting. Almost an over kill. What if we could dumb it way down and make it more approachable. Make it into smaller bite size pieces and then let them get deeper if they want. As a side note, like the ice berg analogy, we only show the most basic pieces. Then, if they want more, we allow them to get to it. Maybe either offer certain packages and/or hide everything by default and make them turn it on (at a corp-wide or world level and also at a payee/user level).

Steve - how do people want to buy things? We then need to cater to that level. See the photo gallery for an inverted funnel analogy. Currently, we have people enter with all options (like the top side of the a funnel) and then have them select what they want to get to the smaller level. What if we flipped that model and started out super small and basic... then they could either buy and/or turn of additional modules and/or features as they need them. So, basically, we start super small (like the bottom of the funnel) and work outward (getting bigger like the top of a funnel).

Alan - would like to do a cognitive walk through... What path do they take to do a task? Where did we want them to go and/or do? Where are their eyes on the page and where are they spending the most time? How easy was it for them to follow the path that is wanted? The cognitive walk through would include a small user group, and then the persons being tasked with the tasks would have to explain (verbal and/or written) what and why they are doing what they are doing. Basically, getting into the minds of the users and what they are seeing, focusing on, and/or actually doing.

Wire frames (interactive outlines) and getting to the basic decisions and taking that research back to the coding project. What is the phycology behind the decisions. What are the human levels that we might be missing and/or could really enhance just by display, menus, and structure. In Dustin's words... "putting rails on things".

We also talked about doing different cognitive walk through groups (users not familiar with the system) and how they would do their own different tasks. If they get stuck, why? What were they looking for and what were they expecting? This is more of a cognitive (brain activity) exercise to see what the thought process is and/or could be. One of the challenges for us might be - so many different business verticals and so many different choices... we might need to get a sample and make sure that we aren't hitting just one niche and/or personality type. Lots of different flares and possibilities. We would like to match who would be using the program with what we would be asking them to do. This testing also has some down-sides, such as preconceived notions, using other existing and/or older products, and actually testing people who would be using it.

Alan and I were talking about who we knew and what resources we could tap into to get some basic testing. Just throwing around some ideas. We added in a new community funded project to get in there and do some research and some of the cognitive walk trough's.

After that, Alan and I were reporting on our different projects. We love the options of having black box code, but there are teeth to that as well. We are starting to see the black box section as a huge time sink for the developers if they are making core changes. We have code that is not in master (in the main code repository), it could be changed at any time, and no one knows who has the last cookie. The developers work directly with the clients, and thus, they think that they have the latest code, but a new change could have been cascaded through to the other pages. We definitely need the black box code options and framework, but we need to eliminate as much duplicate code as possible. It is becoming an issue. It is not on fire, but it becoming a thing that needs to be addressed.

Wayne popped in and reported on the database migration project. He is planning on running some new tests tonight. He went backwards and did some major back testing and going back to a test driven design philosophy. He said that he got a great reminder on why we need to stick with a test driven design philosophy (watching out for the little things). The data migration process is super deep... it is basically allowing two different servers to run as they are... then in the background it takes data and tries to re-sync the data to get a perfect match, even though they are different databases with different auto id numbers. That is advanced mixing and blending.

We got into a bigger discussion about standardizing data and using special tables such as flex grid tie-ins and custom dates, numeric, and custom text fields. Some of those tables are great double agents and/or chameleon type tables (they switch as needed). Good stuff and it really seems like Wayne is trying to think beyond the current project.

We are constantly chasing a moving target... part of the fun... :)

Eric popped in and we touched base fairly quickly on the loyalty points and special tracking accounts. After that, Steve and I were talking about custom code and black boxes. We are seeing more and more needs to template and allow full user interactions. This gets to the custom configuration level.

- Our goal is to get the pages and code out to the object level.

- Currently we have options for black boxes. We may need to go deeper there and allow for custom, theme (bulk black boxes), mini settings, and then the default classic pages.

- The display and sometimes the logic are the things that need to be able to change. The display being one of the biggest thing.

- We were talking about corp-wide settings, users settings, page settings, and even player group settings (12 main players - invoices, customers, items, PO's, etc.)

- Everything keeps fracturing and spreading out. That isn't bad, but it does make it hard to manage and also show back to the users.

- Lots of our users want to limit what is shown. That is removing fields and columns. The opposite for that is real in-line database extensions (expanding the database with specific data types and fields).

- We talked about limiting results back to the users... for most things that works great. On the other hand, other people want everything from forever (all the data).

- We are even seeing a need for page level settings as to what data is pulled back and what data is shown.

- It goes clear out the level of layout and display. Say the shopping cart - I want the clear cart button here. I want the checkout button here. I want the update cart button here. I don't want x and y but I do want z and q. You get the idea.

- We are also seeing a need for logic rules (still at the page level). Basically, how do I play and who do I play with? Rules, assignments, and settings.

- Settings are preset choices so that we could go even faster and faster without asking for input each time.

- Talking about a small game and/or a developer's challenge - a contest of sorts

- If we play with the real data, inside of adilas, we are so interconnected, it gets kind tough. For concepting, we may want to step back and limit the scope.

- Talking about try storming, brainstorming, concepting, and even breaking things into stages.

- Often when we are looking for ideas and solutions, it becomes a mix of multiple ideas. Cinergy and getting multiple people playing the game. Kinda like add on.

- Are we turning right, left, or going up or down... wet clay and things keep changing.

- We are so grateful for all of the people pushing on things. It is always morphing and changing.

- The element of control by a user - easy, powerful, and pretty - if it has those things, you can sell it.

Working with Bryan. We have had a request for being able to switch email addresses and contact info on invoices and quotes. Right now, most invoices and quotes pull in the salesperson info. The original train of thought was helping to make the invoices and quotes a virtual business card. We have done a couple of custom ones, where we switched out the salesperson info with company and/or location specific info or even static contact info. We are seeing more needs for this to happen, being able to switch what is being shown and/or presented. In response to that, we could add a new corp-wide setting that allowed them to make a switch between salesperson contact info and company/location contact info. That is a good idea.

Next, we talked about a company that is currently maxing out the flex grid and the number of custom fields (they are already using 15 custom fields). We talked about expanding that and what that would take. We also briefly talked about the concept of real in-line extensions and also sub attributes with sub inventory. We also talked about tying in the PO line items to elements of time. If you go that route, you have tons more options on the elements of time and subs of time arena. We have lots of tools and options. Sometimes it becomes tricky figuring out which ones to use and how best to mix and blend to get what you need.

• Corp Id or World Id Number
• App Type Id (2=Deposit, 3=Invoice, 4=PO, 5=Expense/Receipt, 6=Balance Sheet Item, 7=Stock/Unit, 8=Customer, 9=Vendor/Payee, 10=Employee, 11=Part, 12=Element of Time, 13=Quote)
• Main Id - What is the corresponding main id number to create the main id and app type id combo? These combos deal at the data level for the data item. For example: App type 2 and deposit number 50. That makes a specific named deposit. Or app type 3 and invoice number 700. That creates an invoice entity or individual. Or app type 11 and part id number 1000. This would be how the system would talk to and/or communicate with a part number or item (general inventory item).
• Sub Id - Optional. This would be a sub id number if we need to connect to a sub. If not, it would be left at 0.
• Table Name - This would be a string or text value that would help us know what table we were talking about. This helps us possibly connect an unlimited number of subs or sub tables.

Currently all sub inventory attributes use these inline data extensions. 

Needs to be extended.

Also increased flex grid from 15 fields to 30 custom fields.

• Working on the new image folder security enhancement stuff. Going through page by page and making changes.
• An intern came over and I helped him with exports to Excel for elements of time.
• More work on photo and image folder changes.
• Brainstorming on how time and subs of time (functions) could be used in conjunction. See notes below and on the following pages.
• Brainstorming and sketching ideas about sub locations and real in-line extensions. See notes on other pages.
• Working on more security updates for the image folder names. Also helped out a developer with a stock/unit request for short cutting the internal-repair tickets for stock/units.