Esto es como un tema de #característica - #desarrollo, no estoy seguro de en cuál debería estar.
¿Hay alguna forma de modificar la configuración del sitio en un plugin? Estoy 99% seguro de que no, pero solo me gustaría confirmarlo.
Si no la hay, ¿puedo proponer una sugerencia para no hacerla inmutable? ¿O quizás, tener alguna API o una forma de ‘desbloquear’ la propiedad inmutable de SiteSettings?
Un posible caso de uso que estoy considerando es incluir una lista de categorías protegidas en una configuración para que al administrador le resulte más fácil incluirlas/excluirlas.
[quote=“NateDhaliwal, post:1, topic:389676”]Un caso de uso posible que estoy considerando es incluir una lista de categorías protegidas en una configuración para que sea más fácil para el administrador incluirlas/excluirlas.
[/quote]
Empecemos por aquí y trabajemos de afuera hacia adentro.
¿Puedes describir primero el caso de uso desde el punto de vista de la comunidad? ¿Qué están tratando de lograr y qué hace que sea difícil hacerlo ahora? ¿Qué característica imaginas que resolvería su necesidad de manera más efectiva (independientemente de cómo se implemente)?
Luego, podemos trabajar a partir de ahí para determinar si esto se hace mejor en un complemento o como una característica principal.
Luego, podemos trabajar a partir de ahí para discutir sugerencias sobre cómo implementarlo.
Asumí erróneamente que dado que la configuración es inmutable en los TCs, también lo es en los plugins en Ruby. Voy a intentarlo.
Sería bueno hacerlos editables en los TCs. Mi caso de uso (para el cual estoy usando un plugin ahora) es que tomo todos los temas y publicaciones en todas las categorías por defecto y hago algunas cosas con ellos, pero no me gustaría incluir categorías protegidas (como una configuración de excluded_categories).
Sin embargo, si fuera posible agregar categorías protegidas a la configuración y luego acceder a ellas, sería más fácil. De esta manera, los administradores pueden incluir algunas categorías protegidas si lo desean eliminándolas de la configuración.
Con la idea de @pfaffman, probablemente se pueda hacer, pero no en los TCs.
El problema con esto es que no conozco las categorías protegidas de antemano.
Si has iniciado sesión como administrador, un componente temático podría cambiar siteSettings a través de la API.
¿Entonces simplemente creas una configuración de componente temático y añades esas categorías? No te refieres a alguna configuración de sitio protected_categories que no se me esté ocurriendo, ¿verdad? ¿Algo como esto?
Me encantaría saber más. Creo que me ayudaría a poner esta solicitud en un mejor contexto.
¿Estás dispuesto a compartir más sobre tu comunidad?
¿Eres el usuario principal de esta característica o hay otros en tu equipo que la necesiten? ¿Tienes documentación orientada al usuario para el flujo de trabajo que depende de esta característica? Si es así, ¿cómo se ve? Si no, ¿puedes describir brevemente cómo podría verse?
@mcwumbly@pfaffman De acuerdo, déjame intentar explicar esto lo más posible.
Estoy desarrollando un complemento que toma temas y publicaciones y los publica en GitHub como archivos Markdown (como un archivo).
Sin embargo, no me gustaría incluir categorías privadas (¿creo que ahora ese es el término correcto?) en esto, ya que son ‘privadas’.
Por lo tanto, estoy buscando una manera de rellenar previamente una configuración con la lista de categorías privadas, la cual no se puede definir dentro del parámetro default, ya que no sabría cuáles son las categorías privadas de antemano.
En caso de que esto se pueda hacer cambiando directamente SiteSetting en Ruby, ¿se puede hacer lo mismo con la configuración (settings) de un Componente de Tema? Estoy bastante seguro de que este último es inmutable. ¿Hay alguna manera de cambiarlo en un Componente de Tema?
No se trata realmente de la comunidad. Estoy intentando esto (con un trabajo de relleno también) a mi manera. Esto guarda cada tema y publicación como un archivo Markdown en un repositorio.
Todavía no sé qué significa privado para ti. ¿Significa que solo quieres categorías que sean visibles para todos, o para usuarios anónimos? ¿O tienes alguna otra definición?
Si quieres esas, entonces tu complemento puede obtener solo esas, quizás mediante una búsqueda a la que le pases un usuario (o tal vez llamando a un guardián), o simplemente verificando los permisos.
O si privado es algo que es una opinión, entonces puedes agregar una configuración.
¿Y probablemente quieras hacer esto en un trabajo que se ejecuta diariamente o lo que sea?
Si estás enviando cosas a GitHub, pensaría que querrías que Discourse lo hiciera en lugar de molestarte con que tu navegador envíe datos a Discourse. No veo cómo o por qué lo harías con un componente de tema.
Quiero decir categorías como Staff, y otras que están limitadas por grupos. Creo que es posible con un complemento (plugin), pero supongo que entonces la configuración de TC no se puede modificar.
¿Entiendo correctamente que se refiere al método Category.where(...) para obtener estas categorías “privadas”? Pero, ¿qué pasa si el administrador quiere incluir (algunas de) esas categorías? ¿Necesito tener una configuración de include categories que contrarreste las categorías “privadas” definidas en el código? ¿Sería contraproducente?
Todavía no entiendo esto. Sí, puedes agregar esas configuraciones en un SiteSetting y sí, el plugin podría leer esa configuración e incluso cambiarla. Pero ¿por qué necesitaría cambiar la configuración dado el escenario anterior?
Suponiendo que tengo 5 categorías: A, B, C, D y E. Ahora digamos que B y C solo están disponibles para algunos grupos. Para evitar que los temas privados aquí se compartan al subirse al repositorio, B y C se añaden a la configuración excluded_categories, junto con otros como, por ejemplo, Staff.
Ahora, suponiendo que al administrador del sitio no le importa que se compartan los temas de B, puede eliminar B de la configuración, manteniendo C allí.
Así que excluded_categories tendría que cambiarse al principio para añadir las categorías “privadas” B y C. ¿No sé si eso tiene sentido?
Aunque eso es perfectamente posible desde un punto de vista técnico, creo que el enfoque sería demasiado complicado, especialmente porque “al principio” es difícil de definir/detectar, y quieres evitar que el complemento siga añadiendo B después de que el administrador del sitio lo haya eliminado. Además, cuando se añade una nueva categoría privada, el complemento necesitaría añadirla, pero debería ser capaz de ver la diferencia entre una categoría nueva (añadir) y una categoría que fue eliminada previamente por el administrador (no volver a añadir).
Optaría por una configuración include_private_categories que comience vacía, y el complemento simplemente procesaría todas las categorías públicas Y las categorías en include_private_categories. Eso te dará muchos menos dolores de cabeza.
Otra alternativa de diseño que podría imaginar aquí es tener dos repositorios separados: uno para contenido público y otro para contenido privado.
El repositorio de contenido privado en sí podría mantenerse privado (podrías determinar quién tiene acceso a él de forma independiente).