Ok, esto probablemente sea una solicitud extraña, así que explicaré mi dilema aquí.
Tenemos una instancia de Discourse con muchos usuarios y, por el hecho de haberse construido sobre dos décadas de listas de correo, tenemos muchos usuarios acostumbrados al modo de listas de correo.
Actualmente tenemos algunas categorías activas, pero no usamos el nombre de la categoría en el formato del asunto del correo electrónico, ya que todos nuestros usuarios de listas de correo tienen años de correos que comienzan con un marcador [SDL] y filtros de correo que clasifican los mensajes en carpetas basándose en esa cadena, etc.
Así que nuestra cadena de formato se ve así, con el [SDL] codificado…
%{optional_re}[SDL]%{optional_pm} %{topic_title}
…y esto ha estado bien durante tres años.
Pero ahora estamos migrando una antigua y obsoleta lista de correo que registra los commits a nuestro sistema de control de versiones hacia una categoría de Discourse, por todos los beneficios que Discourse ofrece sobre las listas de correo antiguas, y ahora tenemos un problema, porque esa lista de correo tenía un marcador diferente ([Commits], por supuesto).
Así que ahora necesito algo en esa cadena de formato del asunto que sea único para la categoría y que pueda usar como marcador, en lugar de la cadena codificada [SDL].
No puedo usar la cadena de slug de categoría existente, porque la mayoría de las categorías necesitarían usar la misma cadena, y aunque no tengan que ser únicas, (asumo que) rompería todas las URL existentes a nuestros foros si las cambio. Tampoco puedo usar el nombre de la categoría, porque la mayoría de ellas simplemente necesitan ser [SDL] y, además, son frases demasiado largas en cualquier caso.
¿Hay algo que pueda usar para esto? De lo contrario, ¿podemos agregar una cadena genérica a la configuración por categoría que sea accesible para la cadena de formato del asunto del correo electrónico, de la misma manera que %{optional_cat}? Por ejemplo, un %{cat_mailsubj} que por defecto sea una cadena vacía?
¡Gracias!
EDITO: aparentemente ya llegué a esto en 2017 también: How to properly alter the database? - #8 by icculus …¿hay una mejor opción, o debería volver a revisar este parche?