Búsquedas recientes
No hay búsquedas recientes

Tom Richards
Incorporación 15 abr 2021
·
Última actividad 22 ene 2025
Seguimientos
0
Seguidores
0
Actividad total
13
Votos
0
Suscripciones
6
RESUMEN DE LA ACTIVIDAD
INSIGNIAS
ARTÍCULOS
PUBLICACIONES
COMENTARIOS DE LA COMUNIDAD
COMENTARIOS DE ARTÍCULOS
RESUMEN DE LA ACTIVIDAD
Última actividad de Tom Richards
Tom Richards hizo un comentario,
Question: Is it possible to remove one of the three social media icons? Or, is it all or none? In an article page source code I see the three sites are an unordered list. I'd like to remove one of them.
Ver comentario · Publicado 22 ene 2025 · Tom Richards
0
Seguidores
0
Votos
0
Comentarios
Tom Richards hizo un comentario,
Since “Article Placement” is an optional column in an article list, it makes sense that you would want to list all placements. But if we aren't using that column, there is no reason to list an article multiple times since the multiple listings look otherwise identical. Perhaps the problem can be solved by showing all the placements only in a list using the “Article Placement” column, and conversely if a list isn't using that column collapse the multiple listings to one.
Ver comentario · Editado 16 dic 2024 · Tom Richards
0
Seguidores
0
Votos
0
Comentarios
Tom Richards hizo un comentario,
I've done this as well on occasion, but what spurred my question is my dislike for having both a link in the body and an attachment at the bottom.
By definition an attachment is something at the bottom of an article, so it makes sense why they show there. What we (and a few others) are looking for is a simple way to, in the article body, link to a document stored in the zendesk domain, which is what your workaround does.
An alternative to your step 1 is to attach the document to another article altogether, e.g., an article whose sole purpose is attaching things to. Then the doc won't also appear as an attachment in the article where you've linked to it in the body. The caveat is to make sure the permissions on the article it's attached to are not more restrictive than the one that is linking to it.
Ver comentario · Editado 27 oct 2023 · Tom Richards
0
Seguidores
0
Votos
0
Comentarios
Tom Richards creó una publicación,
In Guide, for some articles I want to link to an article attachment in the body of the article rather than have the attachment shown at the bottom of the article. I know that in style.css I can hide displaying attachments for all articles:
.article-attachments {
display: none;
}
What I want is to be able to do the above but selectively per article without having to modify a conditional section in a hbs file with specific article IDs. Is this possible in the CSS?
Publicado 29 sept 2023 · Tom Richards
3
Seguidores
4
Votos
4
Comentarios
Tom Richards hizo un comentario,
Thanks. That's the route I'm now on.
Ver comentario · Publicado 25 may 2021 · Tom Richards
0
Seguidores
0
Votos
0
Comentarios
Tom Richards hizo un comentario,
Hi JJ. The method you have described works for users who have the privilege of adding or editing Guide articles. These users, however, are part of a user segment that can see articles viewable to them only. When they sign in to Zendesk, they are taken to our main support page, but it looks no different than any user would see, and they have no banner up top. The way to discover they are logged in is that these additional articles pop into their search results, but something on the main search page, such as a banner or an icon, would be useful.
Ver comentario · Publicado 25 may 2021 · Tom Richards
0
Seguidores
0
Votos
0
Comentarios
Tom Richards creó una publicación,
We're using Enterprise. Certain Guide articles are viewable only by internal users, as set by the "Visible to" drop-down in the article's settings. When an internal user logs in to Zendesk they are initially taken to the same support page that our external users see, but of course when they search the Guide their results will include the additional internal-only articles.
The internal user's login credentials persist in the browser until cleared or until they expire, but as things stand now there is no way for an internal user viewing our main search page to know they are signed in.
Question: What's the best way to configure Guide so that an internal user arriving at our support page can know they are signed in?
Publicado 24 may 2021 · Tom Richards
1
Seguidor
2
Votos
4
Comentarios