Understanding BaaS

BaaS is a full-featured service running in a cloud, usually with not less than 4Gb of RAM serving a minimum of 2 vCPU.

Well, this configuration is by choice. The BaaS structure is distributed and fully scalable. The databases could be located on different computers, using different database servers. The same applies to the web application, running on a JEE compliant server. BaaS fits perfectly on Amazon Web Services, like EC2, EBS and RDS.

BaaS from the foundations

BaaS components, BrightSide and Elephant, are Open Source projects hosted at TiC Foundation. Both can be freely distributed.

How does BaaS integrates with other services?

BlueBee service is a retailer brand example, based on BaaS. As you can see in this graphic, BaaS integrates seamlessly.

Turró.Org BaaS has a self-hosted unique SSO method. Only affects BaaS users and the implementation isn't provided as standard. Developers can implement their own methods by using the IElephantSSO interface.

Relevant features

• Keep me signed feature, substitutes the Remember me.
• Keeps client signature across multiple sessions.
• Users will be able to sign out remotely from multiple equipments.
• Users will be able to track their activity.

Differences when using SSO

• Password is never remembered when using SSO.
• After three months of inactivity, SSO assertions will be removed and user forced to introduce the password.
• Major changes on browsers may invalidate an SSO session. User wil be required to re-authenticate.
• Live links became optional and no longer a default option.

The flow

Single Sign On will be fully deployed on March 19. In order to make it consistent with Live Links and to actually substitute them, changes will follow this roadmap.

BrightSide és un conjunt de mòduls integrables funcionant sobre les llibreries Elephant. Elephant és una aplicació web, executable des dels navegadors d'Internet, amb el control d'usuaris i els rols dels mateixos integrada.

Seguretat

Tot mòdul creat per a Elephant utilitza el sistema de seguretat integrat. Les encriptacions internes es generen usant criptografia simétrica i asimétrica, segons el tipus de clau, i amb claus d'encriptació úniques generades pel propi entorn i diferents per a cada web.

Distribuible

BrightSide es desplega còmodament en la WAN per excelència: Internet. Les bases de dades poden ser distribuides en diferents llocs, segons necessitats d'accesibilitat, capacitat o seguretat.

Multi-plataforma

Elephant, i per tant BrightSide, s'han desenvolupat per a la JEE, Java Enterprise Edition, i es despleguen en qualsevol contenidor compatible amb l'especificació.

Els sistemes operatius soportats son:

• Linux (Centos, Fedora, Debian, Red Hat, Ubuntu, Suse, OpenSuse, etc.)
• Windows (XP, Vista, Windows 8, Windows 10, les diferents versions Terminal Server, etc.)
• Solaris, OpenSolaris
• Mac OS

Multi-sistema d'enmagatzament

BrightSide utilitza el JPA com a Persistent Layer. La configuració del JPA està diferenciada per mòdul, sent possible connectar la majoria de Servidors SQL del mercat:

• MySQL
• Oracle Database
• Microsoft SQl Server
• Derby DB
• Hypersonic DB
• etc.

Client multi-plataforma

El client de Elephant i BrightSide és el navegador d'Internet. Qualsevol sistema operatiu amb navegador d'Internet pot veure planes web i també pot executar l'aplicació. Els navegadors soportats son:

• Chrome
• Firefox
• Internet Explorer
• Navegador Android
• Opera
• Safari
• Konqueror
• Rekonq

El marc per aplicacions de BrightSide és el mòdul sobre el que es construeixen la resta de mòduls de BrightSide. També és el que dona les característiques comunes a l'entorn.

El marc de treball

El marc de treball de l'aplicació està basat en sessions d'usuari. La sessió normal caduca al cap de 5 minuts d'inactivitat, mentre que dins del marc l'allarga fins a 3 hores.

La composició del marc es distribueix en una barra de menús, una barra d'accés ràpid, una barra d'estat i l'espai de treball central. Els llistats i els formularis ocupen l'espai central en forma de pestanyes, cadascuna d'elles independent. Un usuari pot tenir obertes tantes pestanyes com necessiti.

La barra de menús i la barra d'accés ràpid són sensibles als mòduls habilitats i als permisos d'usuari. Quan l'usuari no té permisos per un apartat concret de l'aplicació, l'opció de menú o el menú sencer no es mostren.

La barra d'estat mostra l'usuari autenticat en un component d'informació de contacte que permet la navegació quan es clica a sobre. En el cas d'usar el mòdul de facturació, la barra d'estat mostra també l'empresa.

Les sessions

Una sessió es correspon a un usuari/navegador. Les pestanyes d'un navegador comparteixen la mateixa sessió. L'acció de tancar sessió esborra la sessió actual i en crea una de nova, sense usuari autenticat.

Integració amb els mòduls

Les opcions mostrades dins el marc de treball depenen dels mòduls habilitats. Els mòduls que posa a disposició la Fundació TiC són els que es veuen en la següent gràfica.

Entrar en una plataforma BrightSide on sigueu usuaris registrats es fa seguint l'adreça http://domini/user, com a configuració per defecte. Els propietaris del domini podrien canviar la manera d'accedir-hi segons les seves necessitats.

Estic registrat, però no sé o he oblidat el password

Si s'acaba de registrar, rebrà un correu per poder accedir a la plataforma. Un cop hagi accedit, procedeixi com s'indica a Canvi de password.

Si ha entrat usant un correu de notificació, procedeixi com s'indica a Canvi de password.

Si es troba a l'àrea d'usuari, on es pregunta Usuari/Email i Password, però no sap el password, faci el següent:

• Escrigui el seu Email, el mateix que va usar al registrar-se, en el que rep les notificacions de la plataforma.
• Premi la opció Ha oblidat el password?.

Al moment es genera un correu amb un enllaç per poder entrar a la plataforma. Revisi el seu correu i segueixi les instruccions. Seguidament, canviï el password.

Canvi de password

Vagi a l'àrea d'usuari. Veurà un menú on apareix el seu nom, amb el que es va registrar. Posis a sobre i es desplegaran més opcions. Premi sobre Canviar password. S'obrirà un diàleg on podrà posar el nou password.

Els usuaris amb permisos adequats, poden personificar altres usuaris. Això permet veure les dades tal i com les veurà l'usuari personificat.

Implicacions directes derivades de personificar

Quan es personifica un usuari, les entrades a registre es veuran com l'usuari real, sent la personificació una acció feta per aquest usuari. Així, quan un usuari amb permisos suplanti un altre usuari, en el registre es veurà l'acció Usuari real -> Personifica -> Usuari, usant els noms.

Tot i així, cal actuar amb precaució quan es facin accions que resultin en notificacions. Aquestes sí es veuran com fetes per l'usuari personificat i podria rebre la notificació.

El perquè de personificar

Personificar no està pensat perquè un usuari administrador pugui usar l'aplicació com si fos un altre usuari. La finalitat real, i la més útil, és usar la personificació per saber què pot veure un usuari i com ho veu.

Com personificar?

Podeu personificar des del BaaS o des de l'àrea d'usuari.

• Àrea d'usuari: les opcions sortiran a la part baixa del desplegable amb el nom.
• BaaS: les opcions sortiran al menú de Sessió.

Les opcions relacionades amb personificar són:

• Personificar: permet escollir un usuari a qui suplantar.
• Ser jo mateix: mentre s'està suplantant un usuari, aquesta opció permetrà tornar a l'usuari real.

Les opcions relacionades amb personificar són les úniques que recorden l'usuari real. Així, Personificar continuarà sent visible encara que s'estigui suplantant un usuari que no pot usar aquesta opció.

Per poder personificar, l'usuari real necessita tenir accés al BaaS i poder administrar contactes.

A tenir en compte

La personificació a la web i dins el BaaS són conjuntes. Quan suplantem un usuari, ho fem arreu. Així com la web carrega pàgina a cada petició i l'usuari suplantat es fa evident, cal tenir en compte que si es tenen dues sessions (pestanyes explorador) obertes, una a la web i l'altre al BaaS, i es suplanta des de la web, el BaaS no carregarà pàgina però actuarà com si fos l'usuari suplantat.

Tasques programables

BrightSide permet afegir tasques desl mòduls dins la seva agenda programable. Les tasques programables tenen la finalitat que defineix el mòdul. L'agenda decideix en quin moment s'executaran aquestes tasques.

Entitats programables

Les entitats programables son entitats definides dins els mòduls. L'agenda asegura que una entitat programada executarà l'opció configurada en el moment indicat.

BrightSide Contacts és la base comuna de persones físiques o jurídiques. Els contactes també poden arribar a ser derivats de persones jurídiques, com seus i departaments.

El mínim per poder crear un contacte és el nom. Les dades que se li poden afegir es descriuen a continuació:

Els connectors

Els connectors d'un contacte permeten definir quins sistemes tenim per connectar-hi. També són útils per a propietats d'altres tipus, com veurem en algunes de les convencions del nom de connector.

Els connectors són bàsicament el Nom del connector i el Valor del connector. Els noms de connectors són completament lliures, tot i que alguns segueixen unes convencions per poder ser usats en altres mòduls. Aquestes són els noms de connector amb un ús específic:

indica que l'usuari pot editar-ho en el seu Perfil .

Les adreces

Un contacte pot tenir diverses adreces, diferenciades pel nom. Les convencions pel nom són:

indica que l'usuari ho manté.

Les relacions amb empreses o centres

Les relacions amb empreses o centres permeten crear l'organigrama o organigrames del contacte. Els contactes no estan restringits a una sola relació. Aquesta és una descripció dels camps:

indica que l'usuari pot editar-ho en el seu Perfil .

Els comentaris

Els comentaris són texts lliures associats a un contacte. Alguns prefixes de comentari segueixen convencions de mòduls per donar-hi utilitats concretes. Les convencions són:

indica que l'usuari pot editar-ho en el seu Perfil o en el perfil de l'empresa, si té els permisos.

Integració amb altres mòduls

La gràfica a continuació mostra com els contactes poden integrar-se en altres mòduls, transformant-se en Clients, Dinamitzadors de projecte, Subscriptors de newsletter, etc.

Els contactes s'assignen a grups socials perquè agafin el conjunt de permisos necessaris per funcionar dins el mòduls BrightSide.

Podeu trobar una relació completa a Social groups .

Es contactes poden agafar un rol dins l'activitat dels mòduls. Aquest rol queda definit pels permisos estàtics del Grup social i la participació activa dins un o varis mòduls.

Rols per conveni directament relacionats amb la participació

Variacions previstes

Un cop el funcionament d'aquests rols es va assentant, la intenció és passar-los a atributs directes. Un exemple és el rol de responsable de la relació amb empreses externes. La convenció no contempla si haurà de rebre documents generats per Financials, deixant un buit clar. També les participacions a dossier són clarament insuficients; la convenció respon al text del discriminador de la participació i les competències assignades es veuen diferenciades dins el codi.

Les variacions que es facin tindran compatibilitat descendent i apuntaran a millores més que a substitucions.

El servei BaaS permet la creació d'eines de networking dins l'entorn web de l'usuari del servei, adaptant-se a la imatge corporativa de la web.

La part central del networking dins del BaaS, és la base de contactes.

Contingut

• Objectiu
• Perfil
• Perfil d'empresa
• Relacions
• Habilitats
• Sector i especialitats
• Calendari
• Convocatòries
• Directori
• Tauler d'anuncis
• Darrera activitat
• Públic vs restringit

L'objectiu de l'espai de Networking és posar en contacte als usuaris d'un determinat perfil. Aquests poden editar les seves dades, definir les seves habilitats, indicar el sector on desenvolupen la seva activitat econòmica i quines són les seves especialitats.

Definició dels membres

Els membres de l'espai de networking són els socis i els formants de la junta.

Cal entendre socis i junta com la definició social del grup. Per explicar millor l'exemple, veiem dues definicions de soci en dos mòduls diferents de BrightSide.

El perfil d'usuari és l'espai on l'usuari autenticat gestiona les seves dades, Relacions i Habilitats .

Composició

El perfil està separat quatre seccions: Dades d'usuari, Experiència, Estudis i Habilitats. La secció d'usuari té un contingut fix, mentre que experiència, estudis i habilitats són col·leccions que poden contenir des de zero a múltiples elements.

Dades que es mostren, quan i com

Els perfils es poden veure en diferents llocs de l'espai web del servei BaaS. En algunes ocasions com a emergents, per exemple, en etiquetes o en els noms dels usuaris. En altres, en fitxes de perfil, habitualment en directoris.

En tots els casos, les dades mostrades tenen en compte l'usuari que visualitza i les opcions de privacitat de l'usuari del perfil.

Privacitat

Alguns dels apartats del perfil són controlats per les polítiques de privacitat. Aquestes es veuen com a icones al costat dels camps configurables. El significat de les icones és aquest:

El perfil d'empresa és l'espai on l'usuari autenticat gestiona les dades de la seva empresa. Per a poder editar l'empresa cal ser considerat Responsable tal com es defineix a Relacions .

Composició

Tant contactes com relacions tenen una tipificació interna que apunta a facilitar la creació de noves relacions per part dels usuaris.

La finalitat de les relacions és crear una base d'experiències i estudis mantinguda pels mateixos usuaris.

Contactes i els seus tipus

Els tipus de contactes afecten el perfil i les relacions establertes amb altres contactes, independentment dels permisos d'accés que aquests tinguin i el rol que juguin dins del conjunt de mòduls. Els contactes poden ser de quatre tipus diferents:

Les relacions

Quan parlem d'Experiència o d'Estudis dins del BaaS, parlem de relacions entre usuaris, empreses i/o centres. Aquestes relacions es composen de la següent informació:

Tipus per descobriment

Els tipus per descobriment són aquells que no s'assignen directament com a tals, sinó que es dedueixen a partir dels tipus definits. Aquests tipus per descobriment són bàsics pel Perfil i pels diferents tipus de Directori .

La següent imatge mostra els diferents tipus d'usuaris i les interseccions dels tipus per descobriment.

Vigència de les relacions

S'entén una relació com a vigent, quan es troba dins les dates d'inici i fi. Aquesta vigència es valida amb la data actual del sistema.

Alguns mòduls usen tant el contacte com la seva empresa o centre, per gestionar la participació. En aquests casos, la vigència es valida amb la data de la participació, no la de sistema. Això permet la traçabilitat en les participacions d'empresa o centre.

Procés de validació de la relació

Les relacions iniciades per usuaris autenticats queden pendents de validació. Per resoldre aquest estat, se segueixen unes regles predefinides:

1. Sí l'usuari té un correu amb el mateix domini que el connector web o connectors domini del contacte amb qui es vol relacionar, la relació es valida.
2. Si el contacte amb qui es vol relacionar té un responsable de validacions, se li proposa que sigui aquest qui ho validi.
3. S'afegeix l'opció que sigui un usuari administrador qui ho validi. S'envia avís als usuaris administradors i queda a la cua de pendents.
4. S'afegeix l'opció d'indicar un correu amb la persona que pot validar.

El resultat del procés, en cas de validar-se, generarà un avís pels usuaris administradors. Totes les validacions pendents es veuran en la cua d'avisos dels usuaris administradors.

Si l'usuari escull el cas 4, internament poden donar-se els següents casos:

1. El correu existeix a la base, és de la mateixa empresa/centre i és el mateix que el del responsable de validacions. S'executarà igual que si hagués escollit el cas 2.
2. El correu existeix a la base, és de la mateixa empresa/centre i aquesta no té responsable de validacions. S'enviarà un avís als usuaris administradors perquè avaluïn el cas.
3. El correu existeix a la base, és de la mateixa empresa/centre, però no correspon al responsable de validacions. S'enviarà un avís als usuaris administradors perquè avaluïn el cas.
4. El correu és d'un usuari administrador. S'executarà igual que si hagués escollit el cas 3.

Les habilitats permeten ampliar el perfil d'usuari i són usades internament per a la gestió d'homònims.

Les habilitats se separen en tres tipus:

Els usuaris poden afegir tantes habilitats al seu perfil com creguin oportunes.

Les empreses i centres poden ampliar el perfil afegint sectors i especialitats.

El calendari és una eina associada a l'activitat dins els mòduls del servei BaaS. Això s'explica pel fet que moltes activitats tenen dates associades, siguin d'inici, modificació, finalització i d'altres. Els calendaris són capaços de mostrar l'activitat, lligant-la a l'entitat que l'ha produïda. Així, des d'una data, l'usuari pot arribar fins a l'activitat i acabar consultant els usuaris associats.

Com la resta de components, el calendari és sensible a la privacitat imposada per l'usuari en el seu perfil.

Les convocatòries formen part de l'anomenat Networking, donat que és l'eina per a reunir un grup d'usuaris en unes dates i hores determinades. Els usuaris convocats poden consultar les convocatòries públiques vigents o passades i les convocatòries privades on han estat convocats. En el visor complet de convocatòries hi ha llistat els assistents usant etiquetes de contacte que mostren el perfil emergent de l'usuari.

Convocatòries està explicat a Convocatòries .

El Directori és un llistat de perfils on els usuaris amb permisos poden consultar les dades dels perfils segons les polítiques de privacitat que cadascun dels usuaris del perfil hagin definit.

Els directoris poden ser totals o per tipus.

Es pot trobar informació dels diferents tipus a Relacions .

El tauler d'anuncis permet als usuaris penjar ofertes o demandes de diferents tipus. Aquests anuncis poden estar associats a l'empresa o directament a l'usuari, segons configuració. El tauler d'anuncis és una ampliació dels serveis de contacte.

El Serveis són reservats a les empreses donades d'alta a la base de contactes. La definició d'empresa és molt laxa i es refereix a contactes que tenen treballadors en el seu organigrama.

Els camps d'un servei

Àmbit i permisos necessaris

Els serveis són sempre editables pels treballadors de l'empresa que dóna el servei i pels usuaris administradors. L'aplicació permet enviar un correu de prova als treballadors de l'empresa.

Un servei es pot publicar. L'acció de publicar pot executar-se una sola vegada per part dels treballadors i tantes vegades com vulguin els usuaris administradors. L'àmbit de l'acció de publicar són els subscriptors de la cua Notificacions del lloc web. També pot haver-hi un context dins la web amb els serveis publicats.

Usant els serveis de contactes i les Macros del mòdul, és possible crear un context tipus marketplace.

En l'exemple que es mostra a continuació, el context que mostra el marketplace és /marketplace.

Exemple del contingut de la pàgina

{ @services:all:all:/marketplace:12:#preload}
<div class="ui basic padded segment">
  <div class="ui stackable grid">
    <div class="five wide column">
      <div class="ui segment">
        <h3>{ @res:VIEW_CALENDAR:2}</h3>
        { @marker:calendar:fullcalendar:sources=[servTypes=all;color=#880E0E]}
        <div class="ui hidden divider"></div>
        <h3>{ @res:VIEW_LASTENTRIES:2}</h3>
        { @lastservice-summary:all:all:/marketplace:10:item}
      </div>
    </div>
    <div class="eleven wide column">
      { @dao-search:/marketplace}
      { @services:all:all:/marketplace:12}
    </div>
  </div>
</div>

Com funciona?

La primera macro usa el template fals #preload, per indicar al iterador que carregui els valors previs. Aquests serviran per omplir les llistes de rols, tipus i temàtiques dels serveis, usades pel cercador estàndard per a serveis.

La resta afegiran, a la part esquerra, un calendari i un llistat de darreres entrades. I a la part dreta, el cercador i l'iterador de serveis amb pàgines de 12 serveis màxim.

Exemple de l'arxiu dao-search-marketplace

A Best Practices hi ha un exemple de com afegir un buscador. El template search és part de l'estàndard.

<?xml version="1.0" encoding="ISO-8859-1"?>

<elephant version="1.0">
  <dao-search class="services-search" root="service" template="search">
    <input name="search-value"/>
    <select name="role"/>
    <select name="type"/>
    <input name="actives"/>
    <input name="with-date"/>
  </dao-search>
</elephant>

Configuració específica

El marketplace té configuracions específiques dins l'arxiu service-context.properties que es troba a BaaS -> Eines -> Fitxers -> Configuració -> Propietats. El format de l'arxiu és clau=valor.

Mostrar la darrera activitat és una manera d'incentivar usuaris a ser més actius. Aprofitant LastActivity API i UserLastActivity API de la llibreria Elephant, l'apartat de Networking pot mostrar el moviment dins del servei BaaS.

L'activitat del conjunt

LastActivity API recull els darrers moviments de les entitats del sistema, hi associa el conjunt de participants usant una cerca profunda i, finalment, serialitza els resultats pel seu ús. Per a cada element d'activitat, l'API contrasta amb el controlador de l'entitat si el participant pot veure l'element. Com a resultat, els elements mostrats són específics per l'usuari a qui es mostren.

L'activitat pròpia

L'aproximació usada per UserLastActivity API és diferent. En ser un llistat orientat a l'usuari, la cerca es fa en les activitats específiques d'aquest. El resultat final és un conjunt d'elements restringits a l'usuari a qui es mostra.

Quan es pretén mostrar l'activitat de tercers, els elements mostrats es controlen usant Visual elements .

Tots els mòduls del servei BaaS donen la possibilitat de crear espais públics i espais restringits. La diferència és, en moltes ocasions, subtil. En ambdós casos, les dades a mostrar poden variar la privacitat segons el rol de la persona a qui es mostren. Una única entitat podria ser formada per parts amb privacitats ben diferents.

Característiques dels espais públics i els restringits

Quan es busquen contactes dins l'entorn BrightSide, es possible variar la manera com es busca i concretar els llocs on es busca.

Si simplement introduïm un text, aquest es divideix en paraules i es busca l'existència de cadascuna d'elles dins els diferents camps del contacte.

Variacions al buscar per nom

• El signe = al inici del text, indica que aquest s'ha de tractar com un text sencer, enlloc de dividir-lo en paraules.
• El text entre cometes "text", indica que s'ha de tractar com a text sencer, interpretant els símbols * i ? com a caràcters comodí.

Buscant camps específics

• Connector=Valor s'interpreta com tots els contactes amb Connector conté Valor. Sent Connector el nom del connector.
• Connector= s'interpreta com tots els contactes amb Connector definit. Sent Connector el nom del connector.
• Adreça=Valor s'interpreta com tots els contactes amb l'Adreça definida i algun dels camps conté Valor. Sent Adreça el nom de l'adreça.
• Adreça= s'interpreta com tots els contactes amb l'Adreça definida. Sent Adreça el nom de l'adreça.
• Grouping=Valor s'interpreta com tots els contactes amb l'Agrupació igual a Valor.
• Activity=Valor s'interpreta com tots els contactes amb un CNAE que contingui Valor.
• Relation=Valor s'interpreta com tots els contactes que tinguin una relació del tipus Valor, sent valor headquarters, department, management, administration, sales, purchasing, technical, maintenance, production, quality, hhrr, staff.

Les propostes d'alta poden ser en format vCard o CSV. En ambdues opcions s'utilitzen les convencions vCard amb les extensions BS Contacts.

Els fitxers d'importació han d'usar la codificació UTF-8. En el cas dels CSV, els separadors són punt-i-coma (;) i tots els camps entrecometes (").

Els camps acceptats

Les propostes de relacions són un mètode ràpid per donar d'alta relacions per a contactes existents o nous.

El format de l'arxiu a importar és CSV estàndard. Camps separats per comes i text entre cometes (si cal, quan el text conté comes)

Els camps acceptats

Funcionament

Les propostes d'alta de relació poden generar nous contactes, o simplement crear una relació. Cal tenir en compte:

• Si no es troba l'email, es donarà d'alta un contacte nou. El correu no haurà estat validat pel procés de registre.
• Si relatedTo és un nom que no es troba a la base, és necessari omplir la llista desplegable amb l'empresa o centre.
• El camp position és obligatori.
• Les relacions es validen automàticament.

Quan es marca Enviar benvinguda, un cop finalitzada l'alta de la relació, s'envia un correu de benvinguda a l'usuari.

BrightSide Attachments és el mòdul de base documental. El motiu pel qual s'anomena d'adjunts és perquè permet bases documentals associades a entitats. La base d'adjunts se separa en dos grans tipus, els adjunts pròpiament dits i els fitxers.

Motivació

La categorització de documents segons l'origen, el tipus, les dates i d'altres atributs és un dels grans esculls de les bases documentals. BS Attachments soluciona bona part del problema en automatitzar el procés de crear espais per a documents allà on aquests es generen. Contactes, dossiers, temes, contractes, factures, són exemples d'espais complets de base documental pròpia.

Tot i formar bases documentals separades, el sistema usat per la base d'adjunts, en qualsevol de les modalitats, permet una arrel comuna, visible pels administradors, que facilita la localització dels documents.

Els tipus

BS Attachments se separa en dos grans tipus: Adjunts i Fitxers. Alhora, Fitxers ho fa en dos subtipus: Publicables i Privats. Malgrat la diferència en el nom, tots els tipus són adjuntables.

Tots els tipus d'adjunts poden ser visualitzats a Elephant Web. La diferència principal és que només els Fitxers Publicables són accessibles directament, la resta fan servir visors específics que controlen permisos i activitat. L'ús dels directament publicables és, principalment, imatges, galeries d'imatges i documents públics. Els Adjunts i Fitxers Privats s'usen per a documents privats on els permisos determinen l'accés per part d'usuaris.

Comparativa

El mòdul d'adjunts utilitza convencions per automatitzar l'ús de la base documental dins altres mòduls BrightSide.

Dossiers

L'atribut de participació Veure tots els adjunts controla que el participant vegi o no adjunts amb la propietat publicable.

Per dossiers amb visor públic a la web, la propietat publicable controla si l'arxiu es mostra.

Carpetes segons participació

Quan els participants a dossier ho fan usant els atributs de participació, és possible crear carpetes visibles només pel tipus de participació. Per activar aquest mecanisme es prefixe la carpeta amb el símbol #. El format és #participació, sent participació el nom de l'atribut.

Carpetes segons discriminador

Quan el participant té definit un discriminador, és possible crear carpetes visibles només pels participants amb el mateix discriminador. Per activar aquest mecanisme es prefixe la carpeta amb el símbol #. El format és #discriminador, sent discriminador el valor posat en aquest camp.

Per permetre que un participant pugui veure totes les carpetes amb el prefix #, la propietat discriminador seria *.

Carpetes segons rol

El rol dels participants a dossier pot ser usat com a discriminador de carpetes. Funciona igual que Carpetes segons discriminador sent el discriminador el rol de la participació.

Temes

Per temes amb visor públic a la web, la propietat publicable controla si l'arxiu es mostra.

Contractes

L'atribut publicable controla quan es mostren els documents adjunts al subjecte del contracte, dins els visor de contractes.

Quan s'envia un document per email, l'atribut publicable controla quins documents s'adjunten en el email. La convenció és Mail/[Tipus document]/[Arxiu]. Per exemple, si vol que un document s'envií conjuntament amb les factures d'un determinat contracte, segueixi els següents passos:

1. Obri el contracte
2. Vagi a la pestanya Adjunts
3. Creï la carpeta Mail si no existeix
4. Creï la carpeta Factura si no existeix
5. Pugi l'arxiu que vol adjuntar dins aquesta darrera carpeta
6. Asseguris que la propietat publicable és certa (icona )

Documents

L'atribut publicable controla quan l'adjunt s'envia per email conjuntament amb el document. Per exemple, si té documents relacionats amb una factura i vol que s'enviïn pel correu que genera BrightSide, segueixi els següents passos:

1. Obri el document
2. Vagi a la pestanya Adjunts
3. Pugi l'arxiu que vol adjuntar
4. Asseguris que la propietat publicable és certa (icona )
5. Premi el botó Enviar document

És possible modificar el comportament de l'arbre d'adjunts què es mostra a la web.

Condicions de només lectura

Es crea el context quan la carpeta s'anomena /#ROT (Read Only Terms). Els arxius d'aquesta carpeta seran descarregables només si s'accepta el text contingut dins l'arxiu /_internal/terms/content/rot.txt.

No cal ser usuari registrat. No queda registre de l'acceptació.

Petició de descàrrega

L'atribut Requereix acceptació controla l'accés a l'arxiu. Inicialment és Prohibit. Els usuaris autenticats podran crear una petició de lectura, adjuntant el motiu pel que volen l'arxiu. La petició s'envia a l'usuari que ha pujat l'arxiu, que és qui l'ha d'acceptar. Mentre la petició no és acceptada, l'usuari veu l'estat de Pendent. Un cop acceptada la petició, l'usuari veu l'estat Acceptat i ja pot descarregar l'arxiu.

Els usuaris reben correus en els canvis d'estat. Queda registre del moment de la petició i el moment de l'acceptació. Les descàrregues, al ser un circuit per a usuaris registrats, queden en el registre de l'arxiu i del sistema.

Específic PDFs

Marca d'aigua

L'atribut Marca d'aigua controla que la descàrrega la faci un usuari registrat. L'arxiu que s'entrega conté el nom de l'usuari com a marca d'aigua a totes les pàgines del document.

Si la descàrrega és anònima, l'arxiu és buit.

Els Fitxers són una part de BrightSide Attachment. A diferència d'adjunts, basats en bases de dades, fitxers són directoris i arxius reals.

Els fitxers se separen en dues categories.

Publicables

Són arxius que podran ser llegits directament pels navegadors d'internet. Publicables és útil per imatges o documents dels quals no necessitem un registre d'activitat.

Privats

Són arxius accessibles només des de navegadors BrightSide Attachment amb l'excepció dels components [ Deliverables, Documentation ] .

Usant els fitxers publicables de les entitats BrightSide és possible crear galeries d'imatges. La distribució estàndard inclou un template que segueix les següents convencions per crear galeries.

Galeries d'imatges a partir de Fitxers

Les imatges tindran com extensió .jpg o .png en minúscules.

Dins Fitxers -> Publicables, es busca el directori gallery. Si existeix, totes les imatges dins aquest directori formen una galeria.

Galeries amb nom

Dins el directori gallery és possible crear sub-directoris amb imatges. Les galeries creades usant aquests sub-directoris tindran com a nom el nom del directori.

BrightSide Dossiers permet fer un seguiment relatiu a diferents tipus de informació. Un dossier és un grup de dades i canvis executats sobre aquestes dades. El dossier es pot fer servir com agrupació de documents i compartir-los amb els diferents participants del dossier. També permet el seguiment de temes, amb assignació de informants i responsables.

Usant el dossier com a...

Els dossiers es poden agrupar en categories, que poden identificar-se com a grups de treball.

Al donar nom a les categories, transformem el dossier en diferents tipus de grups d'informació. Aquestes categories son configurables pel usuari, o creades automàticament per altres mòduls BrightSide. Quan es creen automàticament, el dossier o tema queda associat a la entitat que l'ha creat.

Els atributs d'un dossier

Extensions

Tant dossiers com temes poden ser usats de manera no prevista inicialment, només aprofitant el flux de estats dels temes. Es poden crear extensions que siguin visibles a les web, públicament. Un exemple son les preguntes freqüents o l'assoliment d'objectius.

Es possible assignar camps definits a les categories de dossiers. Tots els dossiers de la categoria tindran camps addicionals d'informació.

Camps especials relacionats amb els emails

Les categories de dossiers permeten crear una estructura jeràrquica on assignar els dossiers i projectes que es vagin creant. Aquesta estructura té a més, un ordre jeràrquic real pel que fa als permisos d'usuari.

Les categories formen estructures d'arbre amb tantes branques com calguin. Els usuaris assignats a una categoria tindran els seus permisos propagats per a totes les branques inferiors. Les arrels són aquelles categories que no tenen una categoria pare.

Estructuració i bones pràctiques

L'ús de dossiers i projectes és prou transversal i adaptable com per a permetre crear arbres amb usos ben diferenciats. Un dels punts més feixucs és enfrontar-se a una estructura buida i projectar què necessitarem en el futur. Aquest epígraf és per ajudar a decidir quins són els nostres arbres.

Arrel de gestió i comptable

Aquesta arrel es crea automàticament quan s'utilitza la creació de temes i dossiers des de BS Financials. La categoria arrel es diu Financials i les branques són els tipus de contracte.

Els participants d'aquestes categories solen posar-se només a l'arrel i són part de l'administració de l'empresa.

L'ús immediat d'aquesta categoria és ordenar correctament les incidències produïdes per la relació comptable amb clients, proveïdors, col·laboradors, entitats tributàries i similars. Un exemple ràpid serien: la gestió d'impagats, les no-conformitats, els canvis en factures ja emeses, etc.

Les automatitzacions d'aquesta arrel creen les relacions pertinents entre:

• Contracte i dossier, afegint com a subjecte de dossier al contractant.
• Document i tema, donant nom al tema per poder identificar el document.

A més d'aquestes automatitzacions, és possible navegar del dossier al contracte, del tema al document i a l'inrevés.

Arrel d'àrees estratègiques

Tota activitat segueix estratègies que apunten a corregir-la i millorar-la. Un primer pas és descobrir quines són aquestes estratègies. En el cas d'una empresa de serveis, la categorització dels serveis probablement serveix. Per una empresa de fabricació, segurament seran les línies de treball que permeten que el producte es fabriqui i arribi al destinatari.

Veurem aquestes categories com a grups de treball inter-empresa i dinàmics. Cadascuna d'elles podrà tenir els seus responsables i beneficiaris, oferents i observadors.

Els elements dins aquesta arrel solen ser projectes que compleixen els següents requisits:

• Tenen un títol prou explicatiu.
• Tenen un codi intern de projecte.
• Tenen un objectiu entenedor i publicable.

Arrel d'estructura interna

L'arrel d'estructura interna conté dossiers i projectes que solen ser interessants només per a les parts implicades. Alguns exemples d'aquesta arrel serien:

• Procediments interns.
• Creació de documentació interna.
• Gestió de personal.
• Gestió d'impagats (usant un dossier per subjecte i els visors d'activitat transversal)
• Gestió de packs d'hores (usant hores estimades per crear un tema per factura i hores reals per temes que consumeixin hores)

Els participants d'aquesta arrel solen ser els responsables de cada punt. La part externa interessada participa només en els dossiers que els hi pertoquen.

Les arrels i la seva visibilitat

Filtres per a seleccionar una arrel

Els temes de BrightSide Dossiers apunten accions concretes a una resolució final.

Els temes son un sistema de seguiment. El seu principal objectiu és reunir els defectes, millores, característiques i similars, i redirigir-los a responsables. Per l'usuari, constitueix una eina per solucionar, millorar o realitzar qualsevol objectiu, alhora que reuneix tota l'informació en un sol lloc.

Els atributs d'un tema

Participants

Informant

L'informant és que qui va crear el tema, ja sigui donant-lo d'alta o informant del mateix. Durant la vida del tema, d'altres podran inserir comentaris o obtenir funcions específiques.

Responsable

El tema necessita un responsable. En cas de no indicar quin és, el sistema assigna a la persona que dona d'alta el tema. Responsables són els que poden resoldre el problema, o tenen intenció de fer-ho.

Control de qualitat

Els temes amb un control de qualitat assignat, tenen un pas més a cobrir dins el flux del tema: la verificació. Només el contacte assignat com a QA és qui pot verificar la resolució.

Assistent

No té cap responsabilitat. Només rep informació de com avança el tema i pot afegir comentaris.

Inici i final d'un tema

El tema no necessita de l'existència del control de qualitat, així com qui verifica o tanca els temes. No és important, ja que tots els implicats en el tema seran sempre notificats dels canvis.

Sense QA.

1. L'informant obre un tema.
2. El responsable l'accepta.
3. S'intercanvia informació... (Incidències, comentaris, etc.)
4. El responsable resol el problema.
5. L'informant tanca el tema o si no hi està d'acord, el reobre.

Amb QA.

1. L'informant obre un tema.
2. El responsable l'accepta.
3. S'estableix un QA.
4. S'intercanvia informació... (Incidències, comentaris, etc.)
5. El responsable resol el problema.
6. El QA verifica la resolució.
7. L'informant tanca el tema o si no hi està d'acord, el reobre.

Els temes poden veure's com a llistat d'activitat d'un dossier. Per a dossiers amb molta activitat, aquest tipus de visor té poca utilitat. També és poc útil per a trobar temes concrets quan es desconeix a quin dossier han estat associats. Per a resoldre les diferents necessitats que adrecen els temes, el mòdul de dossiers dóna diferents visors de temes.

Els meus temes

El visor de Els meus temes dóna una visió global dels temes pendents, sigui dins el context de dossier, de categoria o total.

Els meus temes s'ordena per estats, prioritats i tipus, sent sensible a la persona que ho consulta. Dins l'ordenació es contemplen les agrupacions Data sobrepassada, Per fer, Per supervisar, Reunió demanada, Per venir i Congelats. Un mateix tema seria dins Per fer si ho consultés el responsable i dins Per supervisar si ho fes l'informant.

Kanban

És un subconjunt de les opcions que dóna Els meus temes i es mostra en tres columnes: Per fer, En progrés i Fet. El visor Kanban del mòdul de dossiers dóna per fets aquells temes resolts i encara no tancats. Degut a la quantitat de temes que es podrien crear dins un sol dossier, no té massa sentit mostrar els temes ja tancats.

Visor de tasques

Mostra els temes com un llistat de temes, podent seleccionar veure només els oberts. La diferència del llistat normal és que mostra d'una manera molt clara quins són els temes que depenen de la terminació o l'inici d'altres.

Gantt

Genera una gràfica Gantt amb les dades dels temes. Quan no s'han assignat hores estimades, li assigna 1 hora al tema. Si hi ha hores reals, ho mostra en una barra sobreposada.

Graph

Genera un graph amb les relacions del temes. La diferència amb el visor de tasques és que permet amagar els temes que no siguin fites, facilitant la tasca de treballar arbres complexes amb fites.

Les prioritats del tema es numeren de P1 fins P5, sent P1 la més important /greu.

El bon informant

Per a ser un bon informant cal tenir en compte que la persona que rebrà la informació no és dins el context on aquesta s'ha donat. El que segueix és una petita guia pel bon informant:

Omplir el sumari del tema

El sumari és el que surt en els llistats, el primer que es veu del tema. Per això la descripció que es doni en el sumari és la que identificarà el tema.

• Malament: El procés falla.
• Bé: El procés de cerca s'atura en el pas 5 donant l'error 60789.

Incloure informació relacionada amb el tema

Es bo incloure en el comentari els recursos usats, possibles versions o números de sèrie. També està bé posar la periodicitat en que es reprodueix el tema.

Si es coneix, és una bona pràctica incloure un pas a pas per reproduir el cas. També què és el que s'esperava que fes.

Si hi han arxius relacionats, com PDFs, còpies de pantalla... és bo adjuntar-los al tema. Les còpies de pantalla s'haurien de adjuntar en format imatge (JPG, PNG...) ja que així son visibles sense necessitat de descarregar-les.

Fer cas dels missatges que vagi generant el tema

Un cop iniciat, un tema anirà generant missatges segons informin els participants. Un bon informant farà cas d'aquests missatges i prendrà les accions pertinents.

• El responsable respon amb No hi ha prou informació: L'informant haurà de donar la informació requerida i reobrir el tema.
• El responsable respon amb una resolució: L'informant acceptarà la resolució tancant el tema o la rebutjarà reobrint-lo.

És important incloure comentaris en cada canvi d'estat, per fer més fàcil la interpretació del canvi.

No fer copiar-i-enganxar

La informació cal interpretar-la i després escriure el que s'ha entès. Copiar-i-enganxar només pot portar confusió.

Evitar posar noms de persones que no intervinguin

Cal evitar l'esment a persones que no intervinguin en el tema, ja des d'un bon principi. Qui vulgui, o pugui, participar, ja ho farà pel seu compte.

No copiar-i-enganxar text que vingui d'altres converses i que contingui noms de persones. Evitar els 'tal ha dit'.

El bon responsable

Un bon responsable és aquell que resol els temes ràpida i eficaçment. Però també és aquell que detalla el motiu del problema i com ha arribat a solucionar-lo. Saber quin era el problema i què s'ha fet per resoldre'l pot ser de gran utilitat per a l'informant.

Mantenir les formes, per sobre la tensió de la feina

No cal ser educat (salutacions, abraços, etc.) ni fer comentaris punyents. L'ideal és provar a ser sintètic en les descripcions, sense afegir qüestions personals.

Hi ha moments, però, en que la defensa d'un tema pot portar a parlar d'estats d'ànim, molèsties i d'altres similars. És en aquests moments on un punt d'educació ho agrairan tots els implicats.

Els temes permeten portar el compte d'acumulats estimats i reals per a les categories hores, despeses i preu. En l'ús normal, s'entén que els acumulats reals es resten dels d'estimacions, donant l'acumulat restant. Si això ho portem al dossier, aquests treballa amb els acumulats dels seus temes, respectant el tipus d'acumulat i la seva categoria.

Per a tots els casos que es veuran a continuació, els valors imputats a l'agregat tenen el mateix propòsit. És possible mesclar propòsits quan la categoria de l'agregat canvia.

Els usos més habituals dels acumulats

Aquests són casos d'ús adaptats al món real per usuaris de BS Dossiers.

Packs de manteniment

Els packs de manteniment porten la problemàtica dels diferents tipus d'hores. El cas que veurem inclou les hores preventives i les hores d'acció ràpida. La diferència entre els dos tipus és la manera com s'apliquen.

Exemple d'un dossier tipus pack de manteniment

Per adaptar el funcionament a un dossier i portar el control d'hores, seguiríem aquestes passes:

Al final del període contractat, es pot fer un seguiment de les hores contractades (estimades) i les sobrants. Aquest seguiment el poden fer també els clients amb el pack contractat, via els informes per correu o per accés a l'àrea de membres de la web.

Packs d'hores

Els packs d'hores són fàcilment controlables des d'un dossier específic.

Exemple d'un dossier tipus pack d'hores

Per adaptar el funcionament a un dossier i portar el control d'hores contractades vs. gastades, seguiríem aquestes passes:

Des del dossier és visible el nombre d'hores restants al pack.

Control d'impagats

El control d'impagats es pot portar des d'un dossier específic. En aquest exemple usarem l'agregat de preu.

Exemple d'un dossier tipus control d'impagats

Per adaptar el funcionament a un dossier i portar el control dels imports impagats, els documents a què corresponen i les respostes del subjecte del dossier, seguiríem aquestes passes:

En el visor del dossier tindrem les quantitats degudes, les liquidades i el restant. Per aquest dossier és útil el visor d'activitat transversal dels temes. Aquest visor dóna una seqüència temporal de la relació amb el subjecte.

Els comentaris generats quan s'aporta informació d'un tema inclouen una versió text de les dades. Aquest text és el mostrat quan es veu l'activitat d'un tema. També és la informació que s'envia per correu als integrants del tema i en els resums d'activitat dels propietaris de dossier.

Un exemple del text rebut seria:

Usant el parser

Amb la vinguda de les LastActivity com a secció externa de les Newsletter, el comentari d'activitat contenia més informació de la necessària per a cada data mostrada. Això ha obligat a crear un parser del text del comentari que permet tipificar les dades contingudes. El resultat és la possibilitat de retallar i donar format al contigut.

Un exemple de detall amb format de l'informe de darrera activitat seria:

Propietats

Les propietats que separa el parser són: comment, participants, attachments, description, prioritity, type, grouping, dossier, version, publishable, control, delivery, startDate, status, resolution, duplicated, hours, expenses, price, previsionHours, previsionExpenses, previsionPrice.

El mòdul BrigthSide Publication permet convertir un context de la web en:

• Un blog.
• Una galeria d'imatges.
• Publicacions amb subscriptors.
• Publicacions de clau interna.
• Newsletter amb contingut personalitzat.
• Newsletter d'activitat periòdica.

Les categories de publicacions

La categoria de la publicació permet filtrar el conjunt de publicacions, per decidir coses com:

• Dir si és pública o privada.
• On apareix la publicació: resums, menús de filtre, portades.
• L'enviament per cua o directe.
• Mantenir un grups de bloggers.
• Mantenir un grups de subscriptors.

Subscriptors

Les categories admeten subscriptors. Quan aquests subscriptors poden fer manteniment de la seva subscripció, o no, es decideix per categoria. En les categories públiques, els usuaris administren la seva subscripció. Les categories públiques poden també restringir l'accés per grup social; quan és així els usuaris que no siguin del grup social no podran subscriure's.

Els usuaris poden sempre demanar no rebre d'una categoria, sigui o no privada, exceptuant les notificacions de sistema.

Tipus principals de publicacions

• La Publicació , que permet escrits amb contingut multimèdia.
• La Newsletter , composada per seccions. La Publicació pot ser part d'una secció.

Ordenació

Les publicacions s'ordenen per la data de la publicació, editable, en ordre descendent. És a dir, la més nova la primera.

Els bloggers

La funcionalitat per bloggers és estrictament a nivell web i per publicacions no acceptades. No s'entra a l'aplicació.

Es poden afegir bloggers a una categoria. Els bloggers poden ser, amés, administradors de la categoria.

Per veure què es pot fer segons el rol assignat, consulteu aquesta taula:

Públic o privat, resum de funcionalitats

Enviament per correu

Les publicacions s'envien per correu als subscriptors. Una publicació enviada ja no es torna a enviar. L'atribut enviada és editable, així que un administrador pot controlar els enviaments i els re-enviaments.

Quan especificat, l'atribut Retenir fins controla que no es faci l'enviament fins que es compleixi la data i hora.

Llançadores de correu

La forma estàndard d'enviament de publicacions és mitjançant una tasca d'enviament. La periodicitat d'execució d'aquesta tasca és configurable. Quan la tasca troba publicacions no enviades les prepara per enviar als subscriptors de la categoria de la publicació.

Per poder enviar la publicació usant la forma estàndard, cal que l'usuari hagi confirmat els seus Agreements i haver donat conformitat a la seva subscripció en Mail queue .

Una publicació sempre pot ser enviada usant Sendables .

Les newsletter poden veure's com publicacions i també poden funcionar igual. Però són, internament, completament diferents. Així com una newsletter pot fer de publicació, al la inversa és impossible.

La composició d'una newsletter és el següent (només els camps més significatius):

Les seccions

Les seccions tenen propietats comunes i propietats específiques segons el tipus.

Propietats comunes

Tipus de seccions

Propietats per tipus de secció

Gràfica simplificada d'una newsletter

Les seccions externes permeten incloure contingut d'altres mòduls. La comunicació es fa via funcions macro que s'expandeixen en el contingut final. Segons els atributs, una funció pot tornar contingut específic per a cada usuari o genèric per a tots.

No cal escriure les macros senceres. La majoria funcionen correctament amb els paràmetres per defecte.

convocations

Mostra les convocatòries.

convocations([context=<String>];[count=10<Integer>];[template=summary<String>];[restricted=true<Boolean>];[public=false<Boolean>];[future=true<Boolean>])

polls

Mostra les enquestes.

polls([context=<String>];[count=10<Integer>];[restricted=true<Boolean>];[active=false<Boolean>];[template=summary<String>])

dossiers

Mostra els dossiers.

dossiers([status=onwork<onwork|closed|all>];[context=<String>];[categoryIds=<String>];[dossierId=0<Long>];[count=10<Integer>];[restricted=false<Boolean>];[direct=false<Boolean>];[related=false<Boolean>];[template=summary<String>])

projects

Mostra els projectes.

projects(status=onwork<onwork|closed|all>;context=<String>;[categoryIds=<String>];[dossierId=0<Long>];[count=10<Integer>];[restricted=false<Boolean>];[direct=false<Boolean>];[related=false<Boolean>];[template=summary<String>])

issues

Mostra els temes.

issues(status=onwork<onwork|closed|all>;context=<String>;[categoryId=0<Long>];[dossierId=0<Long>];[count=10<Integer>];[restricted=false<Boolean>];[template=summary<String>])

workload

Mostra la càrrega de treball de l'usuari.

workload(context=<String>;[count=10<Integer>];[template=summary<String>])

kb

Mostra el contingut de la base de coneixement.

kb(context=<String>;[count=10<Integer>];[template=summary<String>])

contracts

Mostra els contractes.

contracts([status=active<active|closed|all>];[context=<String>];[count=10<Integer>];[intervention=true<Boolean>];[type=0<Integer>];[template=summary<String>])

last-activity

Mostra la darrera activitat de tots els mòduls dirigida a l'usuari i tenint en compte els seus permisos.

last-activity([context=<String>];[count=50<Integer>];[days=7<Integer>];[path=<String>];[template=summary<String>])

publications

Mostra les publicacions.

publications([context=<String>];[categoryId=0<Long>];[groupId=0<Long>];[count=10<Integer>];[template=summary<String>];[notSent=false<Boolean>];[lang=<String>];[asBlogger=false<Boolean>];[future=false<Boolean>])

challenges

challenges([status=active<active|closed|all>];[context=<String>];[count=10<Integer>];[restricted=false<Boolean>];[studentRelated=false<Boolean>];[challengerRelated=false<Boolean>];[responseFrom=15<Integer>];[template=summary<String>])

Per tal de cobrir tots els casos que permeten les newsletter, la tasca que llança el contingut pels subscriptors és diferent de la tasca d'enviament de publicacions.

Diferències per decidir si enviar

La llançadora de newsletter té en compte que els diferents continguts venen de diferents mòduls. Si la llançadora es defineix com a Necessita disparador, previ a l'enviament, la llançadora comprovarà que hi hagi continguts en aquelles seccions marcades com a Disparador.

Diferències en els subscriptors

Opcionalment, la llançadora pot restringir els nombre de recipients a criteris de mòdul. Un cop seleccionats els recipients, aquests passaran pel filtre de subscripció, on es diu si volen o no rebre de la categoria de la newsletter.

Tot i que és possible crear tantes newsletter com s'enviïn, l'objectiu principal és permetre usar les newsletter com eina de maquetació i captar el contingut de l'activitat dins les bases de dades.

El que segueix són exemples dels diferents tipus de newsletter segons els atributs o la llançadora que s'utilitzi.

Variacions pel contingut

Newsletter tipus informe

Newsletter tipus publicació via números

Variacions per llançadora

Newsletter periòdiques

Newsletter d'activitat

Tant les publicacions com les newsletter s'envien usant diferents mètodes. El més habitual és usar una tasca programada que faci l'enviament, però també poden ser enviades en moments concrets a usuaris determinats.

Per entendre la complexitat dels enviaments, veiem quines són les peces en joc:

Els filtres

Algunes de les peces anteriors actuen com a filtres. La següent imatge mostra els elements a lloc.

Bones pràctiques

Usar categories públiques

Les categories públiques són gestionades per l'usuari. Si no vol rebre d'una categoria, pot aturar l'enviament per configuració. Si vol subscriure's a alguna categoria, també ho pot fer per configuració.

Evitar l'ús d'enviables

Els enviables tenen com a únic filtre els acords. L'usuari és requerit a un pronunciament vers l'acord una sola vegada. Un cop accepta o declina, ja no se li recorda més. Amés, els acords són acumulables per usuari. Un acord declinat atura tot enviament. L'efecte d'això, és que l'usuari no pot aturar l'enviament per configuració i té com a única solució demanar que s'aturi tot enviament.

No fer enviaments massius fora de les tasques programades

Les tasques programades, llançadores d'enviaments de categories de publicacions o newsletter, estan optimitzades per a enviaments massius. Utilitzem tasques d'enviament per lots que eviten ser marcats com spam pel volum de correus.

Dins les tasques programades, evitar l'ús de Guardar i executar, incidint més en una programació correcte.

Tant publicacions com newsletters poden definir-se per a un idioma concret. El resultat és el següent:

Enviaments

Pels enviaments, la diferència està en l'idioma a comparar. S'utilitza sempre la configuració regional del contacte.

La lògica darrera els idiomes

Com a regla general, s'entén posar un idioma quan:

• la publicació o newsletter es repetirà per a la resta d'idiomes, evitant mostrar o enviar contingut repetit.
• la publicació o newsletter està pensada per a un tipus d'usuari determinat i seleccionable per l'idioma.

No posaríem idioma si:

• el contingut només existeix en un idioma.
• el visitant probablement entendrà el contingut, independentment de l'idioma.

Les publicacions són bàsicament un blog. Van lligades a una data, un autor, unes lectures, una valoració i comentaris. Les publicacions utilitzen Mail queue per gestionar les subscripcions de les categories de publicació, així que poden ser enviades per correu a tot usuari registrat que ho vulgui. Les publicacions cobreixen abastament les necessitats de comunicació més habituals, via web o correu.

Si és així, doncs perquè hauríem de voler una nova eina?

Per què usar Newsletter?

Les Newsletter entomen la casuística que comporta l'enviament per correu. Maquetació, formats i continguts sota estàndards que funcionen en qualsevol client de correu.

Les Newsletter, amés, no han vingut soles. Per tal de donar contingut a les seccions externes, s'han creat els ContentProvider. Cada mòdul pot definir els seus per dotar de contingut les Newsletter.

Comparativa per funcionalitats

Funcionalitat per URLs esteses

Les publicacions generen una URL d'accés a la publicació sencera. Aquesta URL segueix les convencions estàndard per URLs fàcils de llegir i acceptades pels buscadors. En una primera versió, les URL són el mateix títol adaptat.

Funcionalitat afegida per imatges

Dins els templates de publicacions, s'ha afegit una convenció de directoris amb funcionalitat per a imatges.

• Les imatges a l'arrel s'afegeixen manualment.
• Les imatges del directori topmost surten després del títol, ocupant tot l'ample.
• Les imatges del directori priorized surten després del sumari, ocupant tot l'ample.
• Les imatges del directori included surten al final del cos, ocupant la meitat de l'ample.

Tant les topmost com les priorized es veuen en el llistat. Les included només quan es veu la publicació sencera.

De la mateixa manera, les topmost i les priorized s'envien dins la notificació per correu.

Funcionalitat per arxius adjunts

Dins els templates de publicacions, s'ha afegit una convenció de directoris amb funcionalitat per a documents.

• Els documents de a l'arrel s'afegeixen manualment via enllaç.
• Els documents del directori attached surten després de la publicació, quan es mostra sencera.
• Els directoris sota attached es mostren com a directoris desplegables.

Els documents dins l'arrel de attached s'envien com adjunts dins les notificacions per correu de categories marcades com Evitar la cua o usant la pestanya Enviable.

BrightSide CRM es composa dels elements que permeten fer un seguiment de les accions fetes pels comercials i tècnics, dirigides a clients i clients potencials, per assolir una venda.

Els blocs principals del CRM son:

1. Acció de venda
2. Prospecció de venda
3. Campanya

Les dades que s'utilitzen per organitzar les accions de venda son:

1. Client
2. Venedor
3. Fórmules de Comissions / Alertes
4. Touchpoints
5. Ideal Target
6. Tipus d'acció
7. Sectors d'activitat
8. Tecnologies

Les accions de venda son el nucli de BrightSide CRM. Son la font del calendari dels venedors, dels resultats de les prospeccions i les campanyes. També permeten crear estadística envers els tipus d'acció i la seva efectivitat. Mantenir al dia les accions de venda dona qualitat a l'informació tornada pel sistema.

Els atributs

Accions de venda dins la prospecció

La prospecció de venda de BrightSide CRM és el conjunt de les accions de venda fetes a un client o client potencial amb un objectiu definit.

Els atributs

Les campanyes de BrightSide CRM son eines per crear prospeccions de venda seleccionant múltiples clients o clients potencials. Al afegir un client a la campanya es genera una nova prospecció de venda, escollint els targets segons es defineix amb Ideal Target.

Els atributs

La campanya vista com la adició de clients per aconseguir prospeccions de venda

El client és el contacte sobre el que es fan prospeccions de venda. Quan el contacte que representa el client té definit l'organigrama, facilita la obtenció de targets usant Ideal Target.

Els atributs

Sumari de client

El sumari de client és on es mostra l'activitat del contacte en altres mòduls de BrightSide. Aquest és un dels avantatges d'una plataforma integrada. Alguns exemples son:

BrightSide Dossier

Mostra els dossiers oberts al contacte, junt amb dades rellevants.

BrightSide Financials

Mostra els contractes oberts al contacte, junt amb l'estat de la cartera.

BrightSide ERP

Mostra les ordres de treball actives del contacte, junt amb dades rellevants.

El venedor és el contacte que fa les accions de venda i a qui se li assignen clients, prospeccions i campanyes.

Els atributs

• Contractes
• Productes
• Documents
• Hisenda Pública
• Informe comptables

Productes per contracte

És posible filtrar els productes que tinguin relació amb contractes de dues maneres:

1. Des del contracte. En la pestanya Productes.
2. Des de la cerca de productes. Filtrant la cerca per Contracte.

Generant assentaments

L'entrada de productes admet els següents casos:

1. Introducció directe del codi. El producte que immediatament validat a la línia.
2. Introducció de codi del contractant. Es pot fer usant el símbol # abans del codi. El producte es valida immediatament.
   
   Per compatibilitat amb altres versions, també es poden usar dos símbols ## o escriure'l directament. En aquest darrer cas, si el codi de contractant no és coincident amb cap codi de producte produirà el mateix resultat.
3. Introducció d'un concepte habitual. El text passa directament al camp concepte i es tracta com a producte no codificat.
   
   La diferència d'aquest darrer cas respecte a introduir el concepte directament, és que l'entrada recorda al darrer preu i l'IVA i els passa als camps corresponents.

Preu proposat al document

• Quan es tracta de compres: el preu és el de darrer cost.
• Quan es tracta de vendes:
• Si és codificat: el preu del article.
• Si no és codificat: el de la darrera venda.

Codis del contractant

Quan un contracte té marcada la opció Usar codis del contractant s'usaran, visualment, els codis definits pel contractant. De tota manera, la cerca de productes funciona igual independentment de com estigui marcada aquesta opció. Quan s'ha buscat per codi i l'opció es marcada, l'entrada troba el codi de contractant correcte.

Seleccionar quin document volem fer

Quan en el filtre es selecciona un tipus document, aquest respon sempre al document que es vol fer. Al dir Rebut Despesa, per exemple, es veurien tots els documents que poden continuar el flux cap a Rebut Despesa, per exemple Factura Rebuda i Venciment a Pagar.

Tallar el flux dels documents

Cadascun dels documents relacionables té com atributs Ancestre i Descendent, visibles en la pestanya Relacions del document. Un document es relaciona amb altres documents en dos sentits:

• Ancestre son els documents del que ve el document.
• Descendent son els documents on va el document, també anomenats Venciment.

Quan un document no té ancestres, és possible desmarcar l'atribut Ancestre per evitar que continui sortint en cartera. El cas és el mateix pel que fa als descendents.

Un document pot programar-se com entitat. Es configura amb el botó .

Les accions programables son:

1. Clonar document: Clona el document en la data indicada. Permet crear documents definitius o esborranys.

Model 111

El model 111 llista les dades per:

• Nom del contracte i nombre de documents relacionats
• Base del càlcul de retencions
• Percentatge de retenció
• Import de les retencions

Les retencions s'agrupen per:

• Retencions al personal
• Retencions a professionals

El model 111 és només a títol informatiu. Els comptes implicats es liquiden fent servir l'opció Liquidacions.

Model 303

El model 303 mostra les dades d'IVA dels trimestres. El desglòs és:

• IVA suportat normal, intracomunitari, extracomunitari i exempt
• IVA suportat d'inversions normal, intracomunitari, extracomunitari i exempt
• IVA repercutit normal, intracomunitari, extracomunitari i exempt

I els totals per a cada cas. Les dades per trimestre i desglòs son:

• IVA
• Import del IVA
• Import declarat
• Import de la base

L'import declarat es fa servir per a dues coses:

• Quan s'ha generat l'assentament: mostra quin import d'IVA s'ha declarat
• Quan no s'ha generat l'assentament: mostra la diferència del declarat al real i que s'aplicarà com a correcció

Els totals del desglòs mostren dues bases, la que es declararà i la real. Seràn diferents si existissin hi haguessin moviments exempts d'IVA.

La generació del assentament

Per a cada trimestre, la fila inferior mostra els totals d'IVA suportat i repecutit. Quan existeix assentament, el camp declarat mostra l'import declarat en l'assentament. Quan no existeix assentament, un botó proposa generar-lo.

La generació del assentament és automàtica, no queda gravat fins que s'accepta i corregeix errors en trimestres passats.

En gravar l'assentament, els comptes d'IVA queden a cero i l'import passa a Hisenda deutora o creditora, segons sigui el cas.

Liquidacions

Les liquidacions permeten pagar o ingressar, segons toqui, d'un dipòsit de tresoreria. Es genera un assentament que liquida els comptes d'Hisenda deutora o creditora contra el compte de tresoreria escollit.

És possible escollir quins comptes es volen liquidar.

Comptes associats al IVA i IRPF

El format dels comptes associats al IVA i IRPF és:

[Major][Modificador].[(IVA|IRPF)*10]

Per exemple:

• IVA suportat del 18: 4720000180
• IRPF retingut del 1.9: 4751200019

Per aconseguir compatibilitat amb versions anteriors on IVA i IRPF no admetien cap decimal en les actualitzacions s'inclou un autoupdate SQL que opera sobre la base afegint un 0 al final dels comptes associats.

Si existeix la 4720000018 o la 4770000018
  Converteix fent: (Digits del 1 al 7) + (Digits del 9 al 10) + 0
Si no
  No facis res

El resultat de la modificació és que els comptes associats perden el vuitè dígit i guanyen un darrer zero.

Comptes de liquidació

Es liquiden els comptes associats a IVA i IRPF contra els comptes acabats en 000. La liquidació de compte associada a compte de liquidació es fa al tancar trimestre. El pagament (o cobrament) es fa en la data especificada.

BS Financials dóna un conjunt d'informes comptables estàndard, més la possibilitat de crear nous informes a mida per l'usuari.

• Balanç exportable
• Configurables
• Fulles d'informe

El balanç és exportable en el format de sumes dels deure i haver. L'exportació permet extreure les dades del balanç de sumes i saldos. Via les opcions d'exportació, també és possible obtenir un format adequat per a taules pivot.

Opcions d'exportació

Exportar el Balanç de Sumes i Saldos

L'escenari correcte és un any objectiu amb l'assentament inicial fet o amb l'any anterior tancat. A diferència de l'opció de balanç del menú, l'exportació força la inclusió de l'assentament inicial quan es demana que s'incorporin, anant a buscar-lo en anys anteriors.

1. Seleccionar l'any objectiu.
2. Seleccionar el mes fins on es vol treure l'informe.
3. Marcar l'opció Incorporar saldos inicials.
4. Deixar desmarcada l'opció Desglòs.

Exportar el balanç en un format adequat per a taules pivot

Les opcions de saldos inicials i desglòs donen l'oportunitat de treure fulles amb més informació i per a diferents propòsits.

És important tenir en compte que quan es demana incorporar saldos inicials i desglòs conjuntament, els saldos inicials són acumulats en el primer trimestre de cada any. Quan aquests s'han trobat en anys anteriors (any objectiu sense assentament inicial), també s'acumularan els assentaments de tancament en el darrer trimestre. Si es vol veure l'evolució trimestral dels comptes, els saldos inicials desfiguraran l'informe. Aquesta regla no s'aplica als comptes d'explotació, excepte quan l'any objectiu no té assentament inicial.

Els informes comptables configurables permeten crear taules amb valors reals de la base de dades Financials usant des de i fins dates.

El format de la definició de l'informe és text JSON i pot configurar-se a Eines -> Arxius -> Informes. L'extensió de l'arxiu amb la definició cal que sigui .json. Els informes seran executables des de Financials -> Comptabilitat -> Informes. Un exemple de definició seria:

{
  "name": "Nom de l'informe",
  "rows": [
    {
      "order": 1,
      "name": "Concepte de la fila 1",
      "regexp": [
        "700.*"
      ],
      "sumType": "CREDIT",
      "negate": false
    },
    {
      "order": 2,
      "name": "Concepte de la fila 2",
      "regexp": [
        "600.*"
      ],
      "sumType": "DEBIT",
      "negate": false
    },
    {
      "order": 3,
      "name": "Total",
      "sum": true
    }
  ],
  "columns": [
    {
      "order": 1,
      "name": "Concepte de la columna 1",
      "regexp": [
        ".*[0-4]"
      ]
    },
    {
      "order": 2,
      "name": "Concepte de la columna 2",
      "regexp": [
        ".*[5-9]"
      ]
    }
  ]
}

Les fulles d'informe BS Financials són informes basats en fulles de càlcul amb configuració de comptes. El módul de fulles d'informe fa còpia de la fulla de configuració i reemplaça les cel·les amb configuració de comptes, pels valors reals de la base comptable.

Es proporcionen dues fulles estàndard que representen el Balanç de Situació en format anual i mensual. Per executar-les aneu a Financials -> Comptabilitat -> Fulles informe. El camp Data serà usat per extreure l'any o l'any i el mes, segons l'informe.

Balanç de Situació

1. Seleccionar Financials -> Comptabilitat -> Fulles informe.
2. En el camp Data seleccionar una data qualsevol de l'any del qual es vol el balanç.
3. Seleccionar la Fulla ComptesAnuals.

• Compres
• Work Order

Fluxe del proces de compres

En la tasca es defineixen els usos requerits:

• Ús de producte. Controla stock, permet compra de codificats i no-codificats.
• Ús de recurs humà. Si és un recurs de proveïdor, genera comanda indicant l'operari, si n'hi ha, i canvia l'estat. En cas contrari, avisa l'operari i canvia l'estat.
• Ús de recurs. Si és un recurs de proveïdor, genera comanda i canvia l'estat.

Inici del fluxe

Es defineix en la tasca i controla quan els usos son visibles a compres:

• Comprar immediatament. Els usos son visibles un cop la tasca deixa l'estat de planificació.
• Comprar al iniciar. Els usos son visibles quan la tasca ja és llesta per començar.
• Comprar al acabar predecessor. Els usos son visibles un cop el predecessor de la tasca està acabat.
• Comprar al iniciar predecessor. Els usos son visibles un cop el predecessor de la tasca és llest per començar.

En tots els casos es defineix un valor de retard. Per exemple, un retard de menys un hora, més Comprar al acabar predecessor, faria que les compres veiessin els usos un hora abans de la previssió d'acabament del predecessor, o el que seria el mateix, una hora abans del moment previst de començar la tasca.

Estats

1. Usos (Recurs humà, recurs, producte)
1. Cap. Encara no ha arribat a compres.
2. Pendent. Hi ha una entrada a compres.
3. Rebut. Hi ha una recepció.
1. Parcialment.
2. Complet. La recepció cubreix el requeriment.
4. Processat. La tasca s'ha acabat.
2. Comandes
1. Cap. Es en la cua de compres.
2. Pendent. S'ha enviat la comanda.
3. Rebuda.
1. Parcialment. Hi han recepcions per quantitats inferiors a la demanada.
2. Completa. Les recepcions donen igual o més a la quantitat demanada.
3. Recepcions
1. Cap. La tasca no s'ha iniciat.
2. Usat.
1. Parcialment. La tasca utilitza parcialment la recepció.
2. Completa. La tasca utilitza la totalitat.

Estat de la tasca

• Planificant. La tasca encara s'està editant.
• Preparada. La tasca ja és visible als operaris.
• En espera. Per motius de data d'inici o dels predecessors, la tasca és en espera.
• Llesta. La tasca es pot començar.
• Iniciada. La tasca ja s'ha començat.
• Acabada. La tasca s'ha acabat.

Canvis en l'estat

El pas de planificant a preparada és responsabilitat de la persona que prepara les tasques.

Una tasca preparada estarà en espera quan:

• Tingui data d'inici futura.
• Tingui predecessors i no es compleixi la condició d'inici.

En la resta de casos, la tasca preparada estarà llesta per començar.

Una tasca iniciada pot passar a acabada quan:

• Ho indiqui l'operari.
• Consti només d'usos de productes i aquests s'hagin rebut completament.

L'API de convocatòries permet crear convocatòries basades en els participants en entitats de qualsevol mòdul BrightSide.

Com funciona?

Les convocatòries es composen dels següents camps:

Organitzador, assistents i calendari

Les convocatòries queden registrades en els calendaris BrightSide de l'organitzador i els assistents. Aquests calendaris es poden importar a diferents plataformes de calendari i dispositius.

Apart del calendari BrightSide, les convocatòries poden enviar-se per correu. Quan es segueix aquest mètode, els correus són de organitzador a assistent, un a un i privat. Dins cada correu s'inclou l'esdeveniment en format iCal. Com el comportament varia segons les plataformes, cal tenir en compte:

• L'organitzador no podrà confirmar-se ell mateix, per tant, no tindrà cap entrada en el calendari.
• Els assistents si que rebran la convocatòria i podran acceptar-la.

Les convocatòries poden usar-se com a control de registre i assistència per a trobades, cursos o qualsevol altre esdeveniment.

Control d'assistència

Els correus enviats als contactes convocats inclouen un codi QR amb un text indicant que servirà per a validar l'assistència.

En el registre d'assistents previ a l'acte els contactes registrats i en possessió del codi QR podran ser validats fent una lectura del codi. La lectura de codi la podrà fer un usuari registrat i pertanyent al grup social Auxiliars d'esdeveniments.

Sistema d'auto-registre a la convocatòria

Una convocatòria pot admetre que els contactes puguin registrar-se (afegir-se a la convocatòria). Quan s'habiliti el registre a la convocatòria, caldrà tenir en compte:

• Els contactes que es registrin rebran immediatament un correu amb el codi QR. Aquest QR serà vàlid fins la data de la convocatòria.
• Per controlar quins usuaris poden registrar-se, s'hauran de poder diferenciar per algun dels rols adquirits del seu grup social dins el BaaS. Habitualment el rol concret es defineix dins xproles-site.xml.

Creant el context de registre

Ens posarem en mode administració web i crearem un context restringit pel rol escollit.

• El rol tindrà la forma [entitat]:[permís] quan s'escullin usuaris determinats.
• El rol tindrà la forma user:in per admetre qualsevol contacte registrat al BaaS.

Un cop creat el context, l'editarem afegint la macro {@entity-ctrl:convocation-ctrl:/convocation/[id_convocatòria]}, sent [id_convocatòria] igual al id de la pestanya convocatòria dins el BaaS.

Visualització de la convocatòria dins el context

Un cop gravat el context, es mostrarà la convocatòria seleccionada. El format serà:

1. Títol de la convocatòria.
2. Etiquetes amb data inici, data final, localització i entitat relacionada.
3. Text de la convocatòria, amb les macros de correu traduïdes al context web.
4. Control d'assistència segons els següents casos:

• Si la convocatòria està esgotada, no es mostra res més.
• Si la convocatòria és vàlida i l'usuari no està registrat, es mostra un botó de registre.
• Si la convocatòria és vàlida i l'usuari està registrat, es mostra el codi QR pel control d'assistència.

La intenció de l'editor wiki és facilitar l'entrada de la Wiki syntax per a pàgines, publicacions i d'altres elements editables.

Flux d'entrada de text

La sintaxi wiki gestiona correctament l'entrada de text normal, creant paràgrafs quan es deixen espais en blanc, o salts simples de línia.

Aplicant estils o agrupant sobre text escrit

Si es selecciona text dins l'editor i s'aplica alguna de les opcions de menú sobre el text, només el text seleccionat es veu afectat. Per exemple, si volem tornar un text a negreta, seleccionant-lo i prement el botó de negreta, l'editor afegirà ** al principi i final de la selecció (negreta en sintaxi wiki).

Seleccionant un text i prement Crear grup d'estils, el grup envoltarà el text seleccionat entre [block][/block].

Botons de la barra de menú

En ordre d'esquerra a dreta:

L’API d’enquestes permet crear grups de preguntes relacionades amb entitats BrightSide.

Com defineix l'API una enquesta?

Una enquesta és un grup de preguntes relacionades amb una entitat BrightSide. Com atributs, l'enquesta té títol, una descripció, una data límit per respondre, la possibilitat d'adjuntar documentació usant el mòdul d'adjunts i atributs de comportament que veurem més endavant amb més detall.

Al mostrar-se, l'enquesta deixa al participant navegar entre l'entitat relacionada i la pròpia enquesta, tal i com es mostra en els següents exemples.

Els atributs que modifiquen com es mostra l'enquesta

Exemples de la mateixa enquesta variant els atributs

Enviar l'enquesta

Les enquestes poden ser enviades per correu. Els recipients seran els participants de l'entitat relacionada. Veiem un exemple usant dos entitats diferents:

El correu mostra el títol de l'enquesta, l'entitat relacionada, la descripció i les opcions a votar, incloent el sentit del vot en cas d'ésser votada.

Overview

Elephant is an application framework based on components. Web Application Developers would not start from scratch, instead will implement standard interfaces. Some of the great advantages of using Elephant are the existing set of components and site administration. Elephant users can expand the site at will, by adding childs to existing pages and selecting whether these childs my or not show in navigators.

Offerings for developers

Take a look at the Elephant building structure. By creating a new component, you are reusing a lot of already working code. Your application will integrate smoothly into already existing web sites, using standard components as: Portal Mailing System, Automated Mailing Lists, Web Search System, Page Scripting, Macro Scripting, etc.

Offerings for web masters and/or final users

Web masters will enjoy using the existing set of components. It gives them full power on web site appearence while makes quite easy creating new pages and their content. Navigation issues are fully supported by Elephant configuration files, with attributes like: Show In Navigators, Tell Robots NOT_TO_INDEX / NOT_TO_FOLLOW, Supported Languages, Internationalized Names, etc.

Page's content is also greatly assisted. When no component is defined, Elephant's DefaultElement takes place. DefaultElement implements what is required to create page content. Repository for images and documents, easy syntax (no HTML, though is permited), version control, author tracking, multi-language support, etc.

One of the magic things that make Elephant easy to use and powerful is the structure is build on. When Elephant takes control you are always in a Context . As for creating web pages, you'll need to understand what a context is and its relation with other contexts.

A context is a web page. We didn't called web page because it seemed too simple for such a marvellous creature, but is nothing more than a web page. Anyway, as to continue making things complicated where they should be easy, we will call this web page a context.

Construction

Context builds up with two different kinds of elements. The actual elements and the layout elements. Despite their names, they respond to a very usual situation. You know how your site should look and don't want to repeat the design for each page. These elements are the layout elements. They are defined at top level, in site's home, and inherited for lower levels.

The image shows what the layout elements are, surrounding the actual content, which is not more than the actual element mentioned above.

By default, the actual element is HTML content, text, written with the special Elephant syntax.

Pages

Elephant sites allow creating as many contexts as you might require, remember a context is equivalent to a page. There is no other limit than the available space and your imagination. Creating pages involve thinking where you want to contruct them. To understand this you might think of your site as a tree. The trunk is the home page. First branches will be home its children and so on. Your tree can have many branches, Elephant will take care to make easy the navigation among them.

Each context has several attributes that define its behaviour.

When you want to show an image in a page, you need first to upload the image file. Where this file goes to it's called repository. Each context has its own repository. So, you have as many repositories as web pages. Each one with its own structure and content.

Elephant maintains different caches to increase performance.

• Site values in site.xml.
• Label bundles.
• Contexts map.
• Social images map.

The Tools menu has an option that allows to reset these caches. Also forces the sitemap generation. Use with caution.

Elephant provides a DefaultElement with edition capabilities. The editor uses the Wiki syntax to ensure a correct HTML result. Also, the wiki syntax, used as is with no classes and styles, is compliant with the email templates. Write once, use everywhere.

The elements at play

This graphic shows the elements that provide content for a web page or an email. By changing the templates root, the marker will generate different layouts. The wiki syntax ensures that the content fits into these templates.

See a complete reference of the available Macros

Templates' root

As noticed above, email templates are not the same than web templates. The main reason is because for web templates we have a complete framework whereas email templates have only a subset. Email clients, or readers, limit the number of CSS and JavaScript features available, making emails a complete different world.

To understand how Elephant deals with those differences, see the button template for an email and for the web.

Email button

<table border="0" cellpadding="0" cellspacing="0">
  <tr>
    <td align="center" bgcolor="${bgcolor}" style="-moz-border-radius:4px;-webkit-border-radius:4px;border-radius:4px;">
      <a href="${link}" style="padding:10px 20px;display:block;text-decoration:none;border:0;font-weight:bold;font-size:15px;color:${color};background:${bgcolor};border:1px solid ${bgcolor};-moz-border-radius:4px;-webkit-border-radius:4px;border-radius:4px;line-height:17px;" class="button_link">
        ${text}
      </a>
    </td>
  </tr>
</table>

Web button

<a href="${link}" class="ui primary button">
  ${text}
</a>

Elephant renders its contexts using layouts.

Template layout is the new default layout for new Elephant versions. In order to make template layout compliant with current table layout versions, template layout makes use of different CSS files.

To activate templates for the whole site, use the template element under layout on the root context. For local templates, those applying to the context where are defined, use the local-template element.

Typical configuration is:

context.xml

<?xml version="1.0" encoding="ISO-8859-1"?>

<elephant-context lang="_en">
  <i18n>
    <name>
      <_en>Home</_en>
    </name>
  </i18n>
  <layout>
    <local-template name="landing"/>
    <template name="web"/>
  </layout>
</elephant-context>

webTemplate.html

<#include "header.html"/>

<div class="webBody" style="width:100%;background:#fff;">
  <div style="width:1000px;margin:auto;">
    <table style="width:100%">
      <tr style="vertical-align:top;">
        <#if nav.hasOptions(2,1,true)>
          <td style="width:25%;padding-top:15px;padding-right:15px;">
            ${nav.drawOptions(false,2,1,true)}
          </td>
        
        <td style="padding-top:15px;">
          <#if traversal>${nav.drawTraversal(true)}
          ${body.startConstruction()}
          <#if traversal>${nav.drawTraversal(false)}
          <#if printVersion??>${printVersion}
          <#if fileVersion??>${fileVersion.render()}
        </td>
      </tr>
    </table>
  </div>
</div>

<#include "footer.html"/>

header.html

<div class="header">
  <div style="width:1000px;margin:auto;">
    <table cellpadding="0" cellspacing="0" style="width:100%;height:40px;">
      <tr style="vertical-align:bottom;">
        <td>
          <a href="${constructor.rootWebPath}">
            <img src="${constructor.rootWebPath}/_internal/repository/logo.png"/>
          </a>
        </td>
        <td>
          ${nav.drawTabulator(1)}
        </td>
      </tr>
    </table>
  </div>
</div>
<div style="width:100%;margin-top:43px;">
  <div style="width:1000px;margin:auto;">
    ${nav.drawLocation()}
  </div>
</div>

footer.html

<div class="footer">
  <div style="width:1000px;margin:auto;">
    <table cellpadding="5">
      <tr style="vertical-align:top;">
        <td>${webmap.draw(3)}</td>
        <td width="20%"><#include "credentials.html"/></td>
      </tr>
    </table>
  </div>  
</div>

landingTemplate.html

<#include "header.html"/>

${body.startConstruction()}

<#include "footer.html"/>

Table layout was the out-of-the-box configured layout from the beginning. Table layout creates an HTML table as the main container. Uses context/_internal/context.xml files to read the configuration. Tipical web root configuration is:

<?xml version="1.0" encoding="ISO-8859-1"?>

<elephant-context lang="_en">
  <i18n>
    <name>
      <_en>Home</_en>
    </name>
  </i18n>
  <layout>
    <element id="20060126192226678" align="top" type="default-container" container="true">
      <attrib name="type" value="header"/>
      <element id="20060126192226654" align="top" type="default-element">
      </element>
      <element id="20060126192226679" align="left" type="default-navigator">
        <attrib name="type" value="tabulator"/>
        <attrib name="level" value="1"/>
      </element>
    </element>
    <element id="20060126192226680" align="top" type="default-container" container="true">
      <attrib name="type" value="locator"/>
      <element id="20060126192226681" align="left" type="default-navigator">
        <attrib name="type" value="location"/>
      </element>
    </element>
    <element id="20060126192226682" align="left" type="default-container" container="true">
      <attrib name="type" value="container"/>
      <attrib name="width" value="180px"/>
      <element id="20060126192226683" align="top" type="default-navigator">
        <attrib name="type" value="options"/>
        <attrib name="level" value="2"/>
        <attrib name="children" value="2"/>
        <attrib name="show-current" value="true"/>
      </element>
    </element>
    <element id="20060126192226685" align="bottom" type="default-container" container="true">
      <attrib name="type" value="footer"/>
      <element id="20060126192226684" align="top" type="default-element">
        <attrib name="type" value="footer-inside"/>
      </element>
    </element>
  </layout>
</elephant-context>

Elephant uses ElephantMarker as the template parser. It's based on FreeMarker and adds the necessary configuration to operate with the Elephant IConstructor.

ElephantMarker uses a template root to locate templates. The template root is configured in the site.xml file.

Templates are used at different levels to generate the final HTML, CSS and JavaScript.

Naming templates

The conventional way ElephantMarker uses to locate a template is by searching [templates_root]/[context]/[name]Template.html. The context variable is the child explained is the above table and helps to differentiate templates usage. Name is the actual template name and the marker appends Template.html.

This convention allows the overriding system Overriding templates .

To understand the override mechanism used by the Elephant library you need to understand how templates are found. By default, ElephantMarker searches templates in /WEB-INF/elephant/[templates_root]/[context]/[name]Template.html, being context and name variables. templates_root is defined in /elephant/conf/site.xml configuration file.

Provided the templates_root is templates-semantic, a context and a name, Elephant will first search /WEB-INF/elephant/templates-semantic/site/[context]/[name]Template.html and, if no file existed, in /WEB-INF/elephant/templates-semantic/[context]/[name]Template.html.

This is a list of commonly used content templates. Does not reflect the actual number of templates available for layouts, entities and email senders.

The banner templates use a JSON source as banner data. Its form is:

• name
• minHeight
• banners (array of:)
• imageLink
• background
• color
• header
• meta
• description
• action
• link
• subaction
• sublink

The most common way to use it would be the marker-jason macro {@marker-json:tmpl-root:template:repository-file}, where tmpl-root is files, template can be bannerImage or bannerCard, and repository-file would be the location of the JSON file.

In the example will be using the banners.json file, located at this context's repository.

With {@marker-json:files:bannerImage:*/banners.json} you get:

With {@marker-json:files:bannerCard:*/banners.json} you get:

Some header

Sub header

Lorem Ipsum is simply dummy text of the printing and typesetting industry...

Visit... Or visit...

Some other header

Some header support

Lorem Ipsum is simply dummy text of the printing and typesetting industry...

Visit...

JSON file

{
  "name" : "slider",
  "minHeight" : "400px",
  "banners" : [
    {
      "imageLink" : "banners/_internal/repository/elementals.jpg",
      "background" : "#00000066",
      "color" : "#fff",
      "header" : "Some header",
      "meta" : "Sub header",
      "description" : "Lorem Ipsum is simply dummy text of the printing and typesetting industry...",
      "action" : "Visit...",
      "link" : "#",
      "subaction" : "Or visit...",
      "sublink" : "#"
    },
    {
      "imageLink" : "banners/_internal/repository/emotion-ocean.jpg",
      "background" : "#ffffff66",
      "color" : "#000",
      "header" : "Some other header",
      "meta" : "Some header support",
      "description" : "Lorem Ipsum is simply dummy text of the printing and typesetting industry...",
      "action" : "Visit...",
      "link" : "#"
    }
  ]
} 

Elephant Users is based on the BrightSide Contacts module. A user is always a contact.

Contacts becoming users

Any contact can be transformed into a user, by giving a connector called Email. Users with this connector can authenticate into the User area and manage their own profile.

If enabled, the User area can also admit new sign-ups. The sign-up process validates the user email. Registered users get the Social Group Guest, with no permissions attached. Administrators receive an email and push notification with the new user name and email.

User's permissions are controlled by the Elephant Security System, explained in Security .

ComplexName property gives the choice of treating users with a chain of formality. The API also offers a guessing option, using the European way of treatment, excluding titles and gender.

Complex name properties

Complex name return

ComplexName will always return a value, despite the property being empty.

In Elephant nomenclature, a user is a contact with an email and able to sign in. Users can also sign up, if the website allows it (has a sign up context)

Automated relations

Elephant gives the user the opportunity to enrich his profile, while getting more permissions. Any user can send a request for a new relation, and acquire permissions once validated. There are some limitations, though, to make sure a single user has not contradictory roles (ex. student and docent)

• Professionals and Docents can not be Students. This could clash regarding challenges.
• Likewise, Students can only be students.

Profile completion

When configured, the profile completion gives the user some tips about completing the profile. Tips may vary, depending on the relation type and what has already been completed.

Using user's profile, any user can add relations to existing companies or learning centers. Relations created by users are moderated, administrators must validate all proposed relations.

When a user has no relations, it is offered several options, depending on the existence of companies or learning centers. If none of them are in your contacts database, nothing will be offered.

The differences among these relations, are:

After a relation request has been sent, the profile will update the status.

Notifications

Activity catchers are mainly related to user activity or participation. Their purpose is to isolate modules from contacts, without losing the ability to react on changes.

Catchers are lists of activities. Activities can be entity participations. Each activity use to contain a user participation. For instance, a user will participate in an issue if has a role within the issue, but not if just commented or participates in issue's dossier.

Assistants

Assistants are users that do not actually participate in an entity, but have entity permissions to assist. An example of assistants is the add by entity combobox. Deep assistants are those who do not assist directly in the related entity, but do indirectly in a parent oriented hierarchy.

Last activity centered

The Elephant system also provides last activity catchers. The activity source might be known or at first unknown. Known sources are data collected from actual entities. The unknown source is basically the log system, in which user activities are registered.

The Agreements API help web administrators to deal with legal issues regarding data protection, terms and conditions.

Why an agreement API?

You may need to warn the user about things like:

• What you do with the collected data.
• The terms and conditions of the offered services.
• Fine-grain previous points by certain actions.

The Agreements API provides a lightweight method to store when a user accepts what the agreement proposes. In order to achieve this, there are some restrictions you should be aware of:

• Each agreement has a single use. Once a user accepts, the agreement can't be deleted.
• Modifying the text, when users already accepted the agreement, it's a bad practice. Currently, you are able to change the text, but in the future this will change, forcing a read-only mode, or deleting all acceptances.
• If you intend to create specific agreements for temporal events, take in mind the single use restriction. Make the text as generic as possible. The benefits are, fewer interactions user/agreement, and a full memory of the acceptance.

How does it work?

First of all, you create an agreement. The main fields are:

What final users will see?

When the required signature forbids sending notifications, a Pending signature notification will be sent. The user will be able to Accept or Decline the agreement from the notification email.

When the required signature forbids operating, the user will be redirected to the agreement, expecting to Accept or Decline the agreement.

The agreement flow

Notifications

Modules chose whether to treat users as Observers or Participants.

The generic rule to follow explains itself better in terms of participation. When a user participates in a module, the participation will prevail to the not signed status.

Publication category subscriptors are not considered participants, but observers. In this case, not signed prevails.

Module actions

Elephant Calendars are a full set of events, generated from application entities. Unlike Activity, calendars also contain future events and a relevant subset of the activity.

Calendars intention is to gather, in a temporal element, information about entities, display a summary and a link to the entity.

Calendar content

Calendars can be configured to show different content, and related-content. To understand what to expect from a Calendar, depending on the context where it's shown, see the tables below:

Calendar entities

Each Non-related Calendar can be configured to display certain entities. The entities that can be configured are:

Calendar popups

Calendar popups are user conscious, showing only what is allowed to see by the target user. If allowed, users can see full detail in the user area, or the corresponding context if configured. For admins, when appropriate, also a link to the application.

Standard calendars provided

Some calendars are provided out-of-the-box, as part of the application functionality.

Calendar for admins

Admins have full access to calendar events using BaaS -> Session -> Calendar.

Elephant Colors API provides some useful methods for manipulating colors. The main goal, though, is finding the adequate font color, based on a solid background. The API can be accessed within templates using the helper object helper.color([name|hexvalue|rgb[a]()]). This function returns a Color object with these methods:

Default palette

This palette is provided as color choosing helper. Any other color can be used with the Elephant Colors API. The palette uses the API to choose the adequate font color using the Color object:

// assign color using color = helper.color('name or hexvalue or rgb[a]()')

<div style="background-color:${color.css()};color:${color.font().css()}">
  ${color_name} (${color.css()})
</div>

Elephant provides a cookie tracking mechanism to allow / decline types of cookies. The Cookie Management's goal is the ability to work in Elephant templates.

API calls in templates

helper.cookies.anyUnset()

helper.cookies.unset(type)

helper.cookies.allow(type)

helper.cookies.decline(type)

helper.cookies.createPost(type, accept)

helper.cookies.createFormAction()

Simple management for analytics cookies

This example will show how to use the cookie tracking mechanism to allow or decline Google Analytics.

First, check if "track" type of cookies is unset and provide a user selection:

<#if helper.cookies.unset("track")>
  Would you allow Google Analytics?
  <a onclick='${helper.cookies.createPost("track", true)}'>Allow analytics</a>
  <a onclick='${helper.cookies.createPost("track", false)}'>Forbid analytics</a>
< /#if>