1) set application behavior variable. this variable will be used throughout the app to conditionally alter the behavior by app type, as needed. can't use FSEvariant, at least in the early going, because there is some cross over in audience. for example, non-clients are logging into the client FS CRM app, and in that case, we want the behavior to be different. FSEvariant we can think of as the container theme, while client.appBehavior will drive functional differences. 2) use this opportunity to invalidate certain combinations of user and app type login. for example, we today allow non-client brokers to log into the FS CRM app. at some point down the road, we will not allow it. also, we will not allow a client broker to login to the 1FS app. other combinations will be checked here, and appropriate action taken. ultimately, we want clean deliniation. no cross over, otherwise it will be confusing. fseVariant values (app versions, or the way it looks): ------------------------------------------------------ CRM: food service crm 1FSBSR: 1FS Broker Edition 1FSDSR: 1FS Distributor Edition (dev) 1FS: generic product catalog, for demonstrating private label solutions (dev) appBehavior values (the way the app behaves): --------------------------------------------- CRM: food service crm used by client brokers and manufacturers 1FSBSR: product catalog app used by client and non-client brokers Future road map for managing app variations, and customizations: ---------------------------------------------------------------- Updated: 06/08/2017 Previously: [fseVariant] was used to identify the specific app, and the look. [appBehavior] was used to drive how the app behaves. For example, the "CRM" variant is a specific app with a blueish theme. It could however behave like 1FSBSR when a specific user logged in. This was necessary, originally, because we only had one app but needed to address client and non-client audiences. This is no longer the case, so a new approach is desired. New Approach: [fseVariant] will be used to identify the specific app, AND app behavior. [fseCustom] will be used to identify any customizations. These will primarily be in the form of styles and graphics, but could also be used to cause changes in app behavior. Changes in app behavior should be limited and minimal though. Making any significant changes to behavior suggests that it should be its own fseVariant. [fseMisc] will be used for miscellaneous purposes. This would be good for testing certain features with a test url. TODO: evaluate each instance of client.appBehavior and convert to client.fseVariant. It should be the case now that there is no cross over behavior with fseVariant. For example, we no longer allow the FSCRM app/container to behave like 1FSBSR. SO, we should now be able to program to fseVariant=1FSBSR and be assured that we are indeed dealing with 1FSBSR behavior. UPDATE: the above is done and will go out in the August 2017 release. New approach examples: For standard 1FS BSR Edition App: fseVariant = "1FSBSR" fseCustom = "" For the Key Impact branded version of 1FS BSR: fseVariant = "1FSBSR" fseCustom = "KEYIMPACT" For FS CRM App: fseVariant = "CRM" fseCustom = "" For 1FS Mfr Edition App: fseVariant = "CRM" fseCustom = "1FSMFR" 8/7/18: additional thinking on new approach For 1FS Mfr Edition App: fseVariant = "1FSMFR" fseCustom = "" For 1FS BSR Edition: fseVariant = "1FSBSR" fseCustom = "" Notes: This is the current 1FS Broker app in the app store. It will morph into the app all brokers use. When a client broker logs in, they will see the same set of home screen icons they see today in the CRM app. All functionality will be the same, but the styling will be different - minimally the light blue style of the current broker app. For non-client brokers, they will all get a consistent home screen with a products and documents icon, and then additional icons in the future for trade and other future builds, such as samples. For FS CRM app: this will eventually be discontinued. We will need to support client brokers and client manufacturers logging into the app for some overlap period. 10/29/18: fseVariant = "1FSBSR" fseCustom = "TEST" fseMisc = "TRADEDEMO" This is being used as a way to test the new home screen layout for 1FSBSR. The new layout gets rid of the mfr icons and incorporates the applet icons that the CRM app uses. When we are ready to switch over to this as the new way, we will copy all of TEST files and overwrite 1FSBSR files with them. TRADEDEMO is simply used for the time being to turn on the Trade icon. It will eventually be driven by portal builder setting. How do we get all brokers (client and non-client) logging into the same 1FSBSR app? 2/12/19: I think we may need to bring back the notion of fseAppBehavior! It went away, as our thinking at the time was separate apps for each audience. The reason we had appBehavior was because we had some audience cross for awhile. That went away as we sorted out the apps and audiences. NOW, we once again will have audience cross over. ALL audiences will use the same app (1FS), so we need a way to control functionality. appBehavior would do this. [fseVariant] will be used to identify the specific app, AND app behavior. [fseAppBehavior] will determine how the app behaves. Mfrs will look at own data, client broker will look at own but augmented data, etc. We could also use this to conditionally drive displays, search criteria options, etc. IMPORTANT: we would determine fseAppBehavior DURING login, whereas fseVariant, fseCustom, and fseMisc would be passed in initially on the URL. [fseCustom] will be used to identify any customizations. These will primarily be in the form of styles and graphics. NOTE: the need for this going forward would be diminished greatly, as only one version of the app would exist. But will keep it for future use. NOTE: we need to convert any business rules that were driven by this to use fseAppBehavior instead. [fseMisc] will be used for miscellaneous purposes. This would be good for testing certain features with a test url.