Recherches récentes
Pas de recherche récente

Tom Richards
Adhésion le 15 avr. 2021
·
Dernière activité le 22 janv. 2025
Suivis
0
Abonnés
0
Activité totale
13
Votes
0
Abonnements
6
APERÇU DES ACTIVITÉS
BADGES
ARTICLES
PUBLICATIONS
COMMENTAIRES DE LA COMMUNAUTÉ
COMMENTAIRES SUR L’ARTICLE
APERÇU DES ACTIVITÉS
Dernière activité effectuée par Tom Richards
Tom Richards a ajouté un commentaire,
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.
Afficher le commentaire · Publication le 22 janv. 2025 · Tom Richards
0
Abonnés
0
Votes
0
Commentaire
Tom Richards a ajouté un commentaire,
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.
Afficher le commentaire · Modification le 16 déc. 2024 · Tom Richards
0
Abonnés
0
Votes
0
Commentaire
Tom Richards a ajouté un commentaire,
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.
Afficher le commentaire · Modification le 27 oct. 2023 · Tom Richards
0
Abonnés
0
Votes
0
Commentaire
Tom Richards a créé une publication,
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?
Publication le 29 sept. 2023 · Tom Richards
3
Abonnés
4
Votes
4
Commentaires
Tom Richards a ajouté un commentaire,
Thanks. That's the route I'm now on.
Afficher le commentaire · Publication le 25 mai 2021 · Tom Richards
0
Abonnés
0
Votes
0
Commentaire
Tom Richards a ajouté un commentaire,
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.
Afficher le commentaire · Publication le 25 mai 2021 · Tom Richards
0
Abonnés
0
Votes
0
Commentaire
Tom Richards a créé une publication,
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?
Publication le 24 mai 2021 · Tom Richards
1
Abonné
2
Votes
4
Commentaires