Quién puede aprobar y cómo lo sabe el portal

Cinco interruptores en cada acceso

Un acceso al portal cuenta con cinco valores booleanos: ver, comentar, aprobar, subir y descargar. El estudio los configura al crear el acceso, y si se solicita un acceso sin permisos, este será de solo ver. Cada ruta del portal declara el único permiso que necesita, y un wrapper comprueba el acceso antes de que se ejecute la ruta, por lo que una ruta nunca tiene que acordarse de realizar la comprobación.

Aprobar es el interruptor clave para dar el visto bueno. La ruta de decisión lo requiere; un acceso de solo ver o solo comentar no puede llegar a la ruta en absoluto, y la respuesta es el mismo rechazo que recibiría un extraño. La página del portal lee los permisos del acceso al abrirse y oculta lo que este no puede hacer, de modo que un cliente con un acceso de solo comentar verá el hilo de comentarios pero ningún botón de aprobar, en lugar de un botón que falle al pulsarlo.

El permiso de ver no está implícito en los demás de forma deliberada. Un acceso que permite aprobar pero no ver es un error que un estudio puede cometer a través de la API, y el producto permite que la ruta de visualización lo rechace para que el estudio se dé cuenta, en lugar de corregirlo en silencio.

Un acceso de proyecto o un acceso de cliente

Un acceso se limita a un proyecto o a un cliente. Un acceso de proyecto ve ese proyecto y nada más. Un acceso de cliente ve todos los proyectos de ese cliente. Un acceso que no esté limitado a ninguno no ve nada, por lo que no puede decidir nada. Si una aprobación concreta depende de este acceso, la respuesta se obtiene aplicando la misma regla a la inversa: la aprobación se encuentra en una tarea, la tarea en un proyecto, y el acceso debe estar limitado a ese proyecto o al cliente de ese proyecto.

El proyecto y el cliente a los que apunta un acceso se comprueban con la propia organización del estudio antes de registrar el acceso, por lo que un acceso nunca puede apuntar a otra organización, y si falta un proyecto o cliente, se devuelve un error de no encontrado en lugar de crear un acceso con una referencia huérfana.

La tarea de recordatorio utiliza la misma regla de alcance para decidir a qué accesos dar un toque cuando una aprobación supera su SLA, de modo que el acceso que recibe el recordatorio siempre es un acceso que podría actuar.

Un acceso por persona

Un acceso tiene una etiqueta que el estudio elige, como el nombre del cliente o de una persona concreta de la empresa cliente. Cuando el estudio crea un acceso para un cliente sin especificar más, la invitación se envía al correo electrónico y al teléfono de contacto del propio cliente. Cuando el acceso es para una sola persona - el responsable de marketing en lugar de la dirección de facturación - el estudio introduce el correo o el teléfono de esa persona y la invitación se envía allí.

Para vincular de forma más segura el acceso a la persona, un acceso puede exigir un código de un solo uso por SMS o correo electrónico además del enlace: seis dígitos, cinco minutos, cinco intentos y reenvío permitido tras un minuto. Un acceso también puede limitar el número de dispositivos, de uno a veinte. Con un límite de uno, si entra un dispositivo desconocido, asocia el acceso a este dispositivo y cierra todas las demás sesiones de inmediato; con un límite mayor, solo se cierra la sesión más antigua. Nunca se expulsa al mismo dispositivo: actualizar la página o perder una cookie no es motivo de penalización.

El historial del estudio muestra, por cada acceso, cuántos dispositivos distintos lo han utilizado. Un acceso destinado a una sola persona que muestra seis dispositivos indica que el enlace se ha compartido, y el estudio puede revocarlo y crear uno nuevo en ese mismo minuto.

Cuando el estudio decide en nombre del cliente

Un productor también puede registrar una decisión desde el lado del estudio si cuenta con la confirmación del cliente. En ese caso, la fila de decisión incluye el ID de usuario del productor y un tipo de actor 'user'. Una decisión tomada desde el portal incluye un tipo de actor 'portal' y ningún ID de usuario. Ambos casos se pueden distinguir en el feed y en el registro de auditoría para siempre, por lo que 'el cliente aprobó' y 'aprobamos en nombre del cliente' nunca serán la misma fila.

Los vistos buenos internos - una fase de aprobación que completa un productor o un director - utilizan el mismo mecanismo, con un miembro del estudio como aprobador y los responsables de la tarea como las personas a las que se les recuerda cuando se demora demasiado.

Caducidad, revocación y lo que ve el estudio

Un acceso caduca a los 30 días de forma predeterminada. El estudio puede establecer de 1 a 365 días, o elegir explícitamente que no caduque; si se omite el valor, nunca se dejará abierto un acceso permanente por accidente. Un acceso revocado deniega la entrada de inmediato. Un acceso revocado se muestra como revocado en lugar de caducado en la lista del estudio, porque un estudio que ha desactivado un enlace quiere ver que lo ha hecho.

El lado del estudio muestra todos los accesos con su etiqueta, estado, permisos, primera apertura, última actividad, dispositivos distintos y el número de aprobaciones del cliente registradas. Antes de que existiera esta lista, la única forma sincera de saber si el cliente lo había abierto era hacer una llamada de teléfono.

La creación y revocación de un acceso se auditan, registrando la configuración del acceso y nunca sus credenciales. Las entradas denegadas también se auditan, y el motivo - no encontrado, revocado, caducado o código de un solo uso requerido - se registra para el estudio y nunca se muestra a la persona que intenta acceder, ya que dar detalles sobre el rechazo serviría de pista para alguien que intente adivinarlo.

• Acceso predeterminado: solo ver, 30 días, invitación a la información de contacto del cliente.
• Aprobar requiere el interruptor de aprobar; la interfaz oculta lo que el acceso no puede hacer.
• El alcance es un proyecto o un cliente; nunca entre organizaciones.