all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||
|
|
|
Yellow
|
|
|||||||||
|
|||||||||
|
|
|
Notes:
|
|
- Do we want to go to int(11) or stay at int(10)? - All normal dates need to be indexed - When adding a new corporation (world) we need to decide if the new world is part of an existing solar system or a standalone new solar system. We have to make a decision… - Once we have the corporation (world) setup in either a new or existing solar system, we can then copy from old world to new world or just let them (the corporation) start from scratch Database Copy & Solar System Stuff: - I am seeing a need for a cluster controller database and a blank master solar system database that will help populate and feed all other solar systems. Basically, we need a controller and a template to copy. - Once the new copy is made, the system will leave the blank template alone. The blank solar system template will only be used when creating a new solar system. No one will actually interact with that database except for admin during scripted updates. - Once we have a good cluster controller database and a blank solar system template database, we need to put copies on all servers. Those will end up becoming templates for all other pieces. o Data 0 o Data 1 o Data 2 o Archive & storage - The goal is to be able to create a new standalone solar system before we worry about copying from the bus (existing shared environment) to the new motorcycle or vehicle. - The copy process is very important but I want to stop selling tickets on the bus so that I can drain the pond. We have to stop the inflow in order to get things cleaned up. I learned that from an old farmer! : ) - Part of the project is documentation. Take the time to get it done and do things right. This includes the Microsoft Word document with table names & descriptions. - On the solar system copy and migrate part. Break things down by letter of each table A-Z. If a letter doesn’t have any tables, still show it, just disable that option. That way, we could always enable it later on if needed. Changes to Make: - Payee table – solar system level o Add a new column o Cluster payee id o Int(10) for the old bus – new, old, documented - Payee login history table – solar system level o Corp id o Cluster payee id o Int(10) for the old bus – new, old, documented Small Check List: - Check application scope vars - Login 1 corp - Login multi corp - Exceed logins - Logout - Look-up username & corps - Switch crop - Record login history - Any payee to any corp - Adding a new user - Editing a user - Admin user edit and reset – cascade down to sub databases - View login history – make corp specific allow for unknowns - Add new corp (standalone) - Add new corp (already existing – solar system) Other notes: - If a user switches corporations (worlds) we need to catch those actions. This will be recorded on the payee login history table. In order to do this, the choose corporation page will have to play a bigger role in the system. It will have to log someone out virtually and re log them in to the new corporation. This will create a foot print of who went where and for how long. If the user logs out, they also get that recorded. Basically, this table will end up being the world the world switching table and history. Any corp that gets visited will be logged – this includes ever brief window shopping. - The store/locations will need to be moved to the session scope. Currently they are recorded in the application scope. The other options is stay with the application scope and put a cluster level list of locations together. Either way. New Cluster Level Tables: Cluster Payee Table: - Cluster payee id - Payee id - Payee type id - Payee first name - Payee last name - Payee status - Payee username - Payee password - Home planet corp id o Create o Select o Insert o Update o Documented - As a special note… reserve the first 100 cluster payee id’s - We may need some customer code to populate Brandon’s & Steve’s id numbers – mini admin function Cluster payee to corp to permissions table: - Payee corp permission id - Corp id - Payee id - Cluster payee id - Payee permission id - Payee corp permission status o Create o Select o Insert o Update o Documented - On any payee to any corp… update both the cluster level and the solar system and world levels Users: - They must exist in a home planet (corp) - At that point, they will be assigned a cluster payee id - That new cluster id will then be recorded at the solar system level to help with a backward look-up - Usernames & passwords will only be able to be changed from the home planet - Payee admin will use the cluster payee table as it’s source - If a home planet is changed - It needs to be recorded on the cluster level - If a payee gets bridged between planes, he or she keeps the home planet id. They virtually become a guest or visitor at that point. Cluster store location table: - Cluster store id - Store id - Corp id - Store initials - Store name - Store status - Store percentage o Create o Select o Insert o Update o Documented - This new cluster store location table will help us keep track of all locations per box or domain - We will use application variables to hold and store all locations for quick look-up Things to do… - Put a new mini method on the top of each CFC page. This will help do a look-up on the corp id and the solar system datasource. Name each method according to the page name. For example: o Cart cfc o “Cluster look up cart” o Amin 1 cfc o “Cluster look up admin 1” - Check every datasource = “___” to make sure it is pointing to the correct solar system, cluster, or correct database - Every method (function within a cfc) needs a call to the look-up function to help dynamically flip the datasource name - We need to check every instance of “applicaton.” ____ or “#application.” - Make sure and record all changes in modified logs and files to upload lists Application Scope Values & Variables: - Main DSN = “ “ fill in the blank - Test & live indicators – from the general table - Cfc paths – “top secret cfc – xyz” - Script path – “top secret secure” - http address – “http://www.adilas.biz” - https address – “https://www.adilas.biz” - Main root folder – “/” - Root folder – top secret - Pdf path – www.adilas.biz top secret pdf - Back up webservice address – (old) – adilaswebservices.biz inventory web components adilas - Use webservice root path – (old) – adilaswebserices.biz inventory - Use content server address – www.adilascontent.biz - Content root folder – top secret - Allow corporation creation – “yes” or “no” - Master SSL web address – “https://data0.adilas.biz/” - Master normal web address – “http://www.adilas.biz” - App mode = “test” or “live” - Qry system defaults = CSS colors & stuff from corp 1 - Qry adilas defaults = CSS colors & stuff from adilas corp - Qry store locations = corp id, store initials, store name, store id, store status, store percentage - Qry time card reasons = qry condition types, qry money types - This one might need some help with new solar systems |