Dakotah Poitra that is actually a setting in Guide admin > Guide settings (gear icon) > Requests > Sort by newest comment to oldest. I didn't have to change the code.
Thanks, Erica Girges I have looked into those resources in the past with no lunch. However, I figured it out by playing with the HTML elements until I got it right. I appreciate the help.
Not sure why the permalink to the comment doesn't work. It should have linked Holly's comment from Mar 29, 2023 above. However, looks like I can paste images now, here's what I was referring to.
We want to move the comment box to the top and the conversation order in descending order from newest to oldest (newest or most recent one on the top right below the comment box).
In our case, we also have the conversation sorted “from newest to oldest” to prevent end users from going to the last page to view the latest comment on the ticket. I'm looking for a way to move the comment box to the top so it aligns with the comment order and to improve the end-user experience
Is there a way we can accomplish this through HTML/CSS/JS?
P.S. It seems the new Zendesk Support theme doesn't allow to attach screenshots :/
Hi Edward Teach, this is a great form! Thank you for sharing. I was able to modify your code to capture a user's name and email so we can get more valuable feedback, track these feedback tickets more closely, and follow up with the submitter if needed. However, I noticed it's not working for signed-in users. Curious to know if you've developed a way for the form to work for signed-in users?
Ability to report on name, email, and organization of users subscribed to a particular topic in Gather
Feature Request Summary:
Ability to report on users subscribed to a particular topic in Gather, including names, email, and organization. Other details such as when they subscribed or other activity would be a plus.
Description/Use Cases:
Our company hosts a monthly webinar for users subscribed to a specific topic in Gather. We send email invitations to this group of users prior to the webinar. Today, there is no easy way in Explore to report on who those users are.
As a workaround, I have to defer to the API to GET the users subscribed to this topic, parse out the user IDs, and run another API call (runner in Postman) to GET the user names and emails. After that, I do some spreadsheet magic to extract the user's email domains and associate them with their organization names.
As you can see, the ability to get a list of names and emails of users subscribed to a particular topic is a very manual and time-consuming process that requires in-depth technical knowledge, let alone allowing access to the API which if not used correctly, could lead to unintended consequences.
We are seeking a way for Community managers to report on this data without the need to run API calls since not all community managers have the technical depth to build and run APIs. I hope this makes sense.
Business impact of limitation or missing feature:
This is currently a blocker for some of our Community managers who are not tech-savvy and hurts productivity. This task is reduced to only a few folks who are knowledgeable and have access to Zendesk API for our instance and this API work around creates dependencies.
Thanks, Ifra Saqlain We are getting odd behavior. We have 4 topics and we are looking to accomplish the following for each topic.
Topic 1 - Public topic. Everyone is able to see and post.
Topic 2 - Visible to everyone, but only Admins and agents can post in this topic, not end-users. This is where the .nesty-panel li:nth-child(#) styling is helpful.
Topic 3 - Visible to a user segment only. Only admins can post in this topic, end users cannot post here.
Topic 4 - Visible to a user segment only who can view and post. Admins can post here as well.
The Who can manage posts setting is set to Agents and admins for all topics. Yet, when the .nesty-panel li:nth-child(#) styling is applied to topics 2 and 3, it removes topics 2 and 4 from the list for admins.
I'm not good with code at all, everything I've done has been by following suggestions in this community. But I'm wondering if a condition that states "Unless the user is an admin, users cannot post in topics 2 and 3" would be better in my case.
Hi Ifra Saqlain, your contributions around the community are always very helpful, and this one is no different. Thank you for being a great contributor.
I do have a question. In my case, it looks like {{#if signed_in}} applies the condition to Admins as well it hides the topics in the .nesty-panel, thus blocking us admins from posting in those topics.
Do you have a suggestion to make all topics available in the .nesty_panel for Admins regardless of any restrictions for end-users? I'm using theme version 1.0.0 with jQuery. Thanks in advance.
