# Pense-Bête ## Réflexions autour des urls d'application ### Constat après feature CMD La table ApplicationUrls ne sert à rien. Comme une application a été matérialisée pour les sites Admin, Medecin et Visio de l'organisation Entoria, elle ne contiendra qu'une url par application. Son seul intérêt est pour les envs de dev qui sont attaqués en local par les développeurs Front. Et pour cet usage, une colonne LocalUrl (voire LocalPort) suffirait. ### Une autre vision En supprimant les applications Entoria surnuméraires (à l'exception du site Patient qui est spécifique), et en affectant les urls aux applications MD historiques, on retrouverait une application avec plusieurs Urls. Auquel cas, c'est la table ApplicationUrls qui porterait l'organisation, ce qui correspondrait exactement à ce que l'on fait dans le code, au moment du login dans le SSO (ie récupération de l'organisation grâce à l'url). Dans ce cas, on supprimerait la colonne RefUniverse de la table Applications. Resterait le problème des profils, qui nécessiteraient d'être rattachés via un lien tripartite entre eux, l'application et l'organisation. ## Réflexions autour des services ### Constat après feature CMD Pour créer le Service Controle Médical, il a fallu sélectionner les bons profils, le bon produit et la bonne spécialité. L'idée semble être de créer un Service Controle Médical générique, dans lequel on pourrait mettre d'autres produits/profils pour des futurs clients du type d'organisation "Contrôle à distance". Ce qui devrait fonctionner au niveau du login, l'utilisateur étant rattaché à une seule organisation, qui filtre ses produits et profils. Il faudra néanmoins au plus vite faire apparaître l'organisation (dropdown) - ou au minimum, le type d'organisation - qui servira de filtrage pour la spécialité, les profils et les produits disponibles. ### Les options Par contre, quid de l'option de service ? Ne serait-ce pas plutôt le type d'organisation qui porte cette option ? C'est en tout cas elle qui semble porter le workflow. De plus, voici