Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6164 Ideas

    sarahmiracle
    sarahmiracleVIP ⭐️⭐️⭐️⭐️⭐️

    Issue when updating notification preferences when adjusting for NXT or SFDC Hybrid Preferred NotificationsNew Idea

    I received a Slack message from a new user the other day telling me that she received an email notification about a new CTA that had been assigned to her, and when she clicked the link to take her to the CTA, she received an error message.She shared the error message with me, and I could tell that the link was directing her to log in through the SFDC Hybrid Gainsight managed package. While we sync users to Gainsight using the SFDC User Connector, our users work out of NXT and not SFDC. Many of them don’t even have the permissions to use the NXT managed package.The first problem here is that because we are syncing in users from SFDC, it is defaulting notification preferences to SFDC hybrid. I don’t want that, and it means I’ll need to reactively update any new users’ preferences to set to NXT.Now the second problem, is that I know a user can make these changes for themselves, however they need to do so from within SFDC Hybrid. Because my users do not have permissions to use NXT in SFDC, they aren’t actually able to update their own permissions.Then the third problem comes in when I tried to mass update all of my users. It has been some time since I’ve checked my new users’ notification preferences, and I figured it was just a good idea to set all my users in bulk to NXT as their preferred for notifications. I followed the steps in the help article, but then I noticed odd behavior. Here’s what happened:Navigated to User Management > changed source to SFDC Clicked the box at the top of the user list to select all in the page view Then clicked the box that said “Check all 77 users” (so that I could choose all users, not just the 25 in my page view) Clicked the three dot menu to change notification preferences Received the message below telling me that 25 users would be changed even though 77 were selected  As a workaround, I needed to change my pagination to view 100 records on a page, then select all, then update preferences. This post is to request that:We allow admins to determine the default preferred notification setting for all users regardless of how the user was synced into Gainsight We allow users to change their settings natively within Gainsight NXT We fix the bug experienced when trying to bulk-update user notification settings preferences

    bjoern_schulze
    bjoern_schulzeHelper ⭐️⭐️⭐️

    Better image handling (2): Have an automatic scaling processOpen

    I want to propose two significant changes in terms of image handling, that will vastly improve the performance, cost-effectiveness and userfriendliness of the platformMake it possible to reuse images and assets Have an automatic scaling processHave an automatic scaling process(I’m using the example of badges, but this also works for other images and assets on inSided.) On inSided, you can upload images and assets with upto 5MB filesize. And every time this image is needed in the frontend, it is being loaded in its original filesize, no matter what image dimensions the image is being displayed in. So for example, you can upload badges with image dimensions of 480x480px that are 2MB large.So every single time any user opens a topic and any of the commenters has earned any of the badges, a 2MB large badge image will load and be displayed with 20x20px image dimensions. If you have a topic with several users that have earned badges, you can multiply the 2MB by the number of users. The same happens on user profile pages or in the leaderboard (only with slightly larger image dimensions).There is no need at all to load an image in its original image dimensions and its original file size, only to scale it down to a smaller width and height afterwards. This is very costly on a performance level and it increases loading times immensely.Therefore, I propose that scaling should take place before the image is being loaded. It is known in what image dimensions the most common assets are being displayed in (badges, hero banner, category icons, etc.). So when an asset is being uploaded, inSided should then automatically create copies of these assets in the needed image dimensions. So when a 20x20px image is being displayed, only the 20x20px image with less than 100kb filesize should be loaded instead of the original file.In combination with making it possible to reusing images and assets, both new features will have a great positive impact on loading times and therefore on userfriendliness. Also, it saves (AWS) costs having a smaller page load.

    bjoern_schulze
    bjoern_schulzeHelper ⭐️⭐️⭐️

    Better image handling (1): Reuse images and assetsOpen

    I want to propose two significant changes in terms of image handling, that will vastly improve the performance, cost-effectiveness and userfriendliness of the platformMake it possible to reuse images and assets Have an automatic scaling processMake it possible to reuse images and assets(I’m using the example of hero images, but this also works for other images and assets on inSided.) If a community wants to use the same hero image for different parent categories and categories, you have to upload the same local file several times, which creates several online files (one for each upload).So if if this hero image is 200kB large and you want to use it in ten different (parent) categories, your cloud space now occupies around 2MB of data instead of 200kB. This costs money (maybe primarily for inSided, but still). If you open each of the (parent) categories in the frontend, the hero image loads every single time, instead of loading it once and then storing it in the cache. This costs loading time (and negatively affects the platform performance).Therefore, I propose to have an asset (or media) center. You can upload images and assets into this cloud directory, can pick files from this directory and use them in different places and use cases. This will improve the performance of the platform because the caching can be utilized more effectively and loading time will go down significantly.

    rhallExpert ⭐️

    Platform visibility needs changing to allow admins to access the Community when it is offlineOpen

    If you are wanting to make significant changes to your Community which require both changes in the admin console and via the Community “Customize” button, you cannot do this in offline mode. Therefore you cannot make these changes without users being able to see incremental changes. This isn’t ideal for some situations. There needs to be an option to allow admins to customise the Community user interface (widgets, CSS, etc) while the Community is offline. There are some areas where the UI is easier to edit directly, but the changes can be made via the admin console (phrases for example). But there are some things you can only do via the “Customize” button in the UI (widgets, etc).I have got around this by using this code in the “Insert in <HEAD>” section of the “Third-party Scripts”….<style> body{ display:none;}</style><script>//Maintenance Screenlet useMaintenance = false; // Set to true for the maintenance window and false for the normal screen.if(useMaintenance){ document.addEventListener('DOMContentLoaded', function() { // Check if the current user is an admin var isAdmin = checkIfAdmin(); if (!isAdmin) { // Prevent default page load and display maintenance message for non-admin users document.body.innerHTML = '<div style="text-align:center; padding-top: 20%;"><h2>Maintenance Message</h2></div>'; } }); }// A simple check using the inSidedData JSON to see if the user is an adminfunction checkIfAdmin() { if(inSidedData.user.role === 'roles.administrator'){ return true; }else{ return false; }} </script>All this does is switch off the body from displaying...this prevents the page being seen at all, otherwise you can see a glimpse of the page before your code rewrites the body object. It then checks to see if the maintenance window is required. If it is required, it checks to see the role of the user. If the user is an admin, it loads normally. If the user is not an admin, it will display a maintenance message.There is one more change that is required, this is to switch the body back on. To do this, go to the “Before </Body>” section and add this code…. <script>//Switch on the body displaydocument.body.style.display = 'block'; </script>I hope this helps.