Settings and activity
8 results found
-
0 votes
An error occurred while saving the comment -
2 votes
An error occurred while saving the comment Thank you for submitting this request! We have added this item to our backlog for future consideration and prioritization.
Existing Page Filtering -
Currently Spire offers page filtering options that can be used alone or in combination to reduce the page tree to meet the selected filter criteria. Filter criteria for 'Language: Missing - [language code]' is available and once all translatable content has been completed the page would not appear if this filter has been applied. (see screenshot)
https://support.optimizely.com/hc/en-us/articles/4413199744141-Filter-pagesI encourage those who would like additional color/visibility on the widgets themselves to vote for this request but wanted to make sure the existing filtering was known in case it is helpful in your current work process.
-
7 votes
An error occurred while saving the comment Thank you for submitting this request!
The design of Search v2 is that the base code produces a default result that can be then modified by partners before uploading to Elasticsearch. This method has corrected an issue in Search V1 where partners could modify the database query in unpredictable ways.
We saw making changes or bugfix in the base code previously in v1 was much more likely to break compatibility with partner customization than we've seen in v2.
Understanding of Impact - Based on the current feedback it sounds like while you are able to create the customization in the existing framework you find that it is cumbersome and taking more time/effort than desired to meet project needs.
If I have misunderstood the impact or you would like to include additional details please feel free to update this request.
-
1 vote
An error occurred while saving the comment Currently this can be handled at the project level with a customization made by implementation partner.
Although we cannot guarantee a release date, we will will include this in our roadmap discussions for future roadmap inclusion.
As part of an initial review we will be hoping to incorporate an out of the box setting for when sessions are fully expired with the following considerations:
- Session Expiration and let the client decide if they would like to redirect to Session Expired Page, or use Overlay with Session Expired Modal on same page.
- In this setting we could also provide additional sub-setting with ability to enable a session expiration warning (admin can set the number of minutes)If there are additional considerations we should keep in mind please continue to add feedback.
-
1 vote
An error occurred while saving the comment Thank you for submitting this request! I believe this is being reported based on an earlier version of our application and has been resolved, please review the changes that have been made and if there are still ongoing concerns. We have made a number of changes to help protect our client users from making unintended changes, using this setting improperly, resulting in a destructive action.
Below are the changes that have been released in Cloud between December 2023 and January 2024 (screenshot is attached to this request for visual display) -
1. Limited User Role Option to a single 'high level CMS Administrator' user role only, and hid the option from view for all other user roles
2. Renamed from 'Restore Content' to 'Sitewide Content Reset' and move under Content Management alongside "Import/Export Content" and "Redo Page State"
3. Improved description within the modal presented to the User
4. Disallow and rename 'continue' button - Empty text box for User to fill in is present to confirm their action, once the user enters their full username the "Reset" button becomes active -
1 vote
An error occurred while saving the comment Thank you for submitting this request! While we do allow configuration of max character limits in the Application Dictionary for some fields; we do have a database nvarchar limit of 255 characters for Attribute field which cannot be easily increased at this time and could cause additional risks.
Do you frequently have attributes greater than this limit or is this an edge case for the "Suitable For Use With" use case?
There are current alternatives for this particular use case that could be approached by reaching out to an implementation partner customize it using the extensions table.
We do encourage facetable attributes to be as small and 'normalized' as possible. If these model numbers/data were normalized in ERP or integration layer it could be brought over as individual attributes. As individual attributes the users on the front end can interact with them with greater flexibility. -
2 votes
An error occurred while saving the comment Thank you for submitting this request! We have updated this request status to Gathering Feedback for future consideration and prioritization.
Sliders, and Swatches have been mentioned to which I'll assume are currently the 'most important' options which are missing. Please feel free to add more comments to this request if there are other important display options to keep in consideration.
-
1 vote
An error occurred while saving the comment Thank you for submitting this request!
Questions regarding the flexibility of this type of control:
1. Is this a setting that would be necessary to change based on the Site/Customer/Location?
2. Would there be a time where one location or customer would be allowed to purchase over max where another would not?
We may be reviewing and improving the VMI-ReOrder website flow in the near future, and I would like to review this type of setting in relation to the upcoming project. Having a better understanding of the desired flexibility will help ensure we are keeping the desired use cases in mind.
Thank you for submitting this request. Currently we are not already referencing this package and as such we cannot approve this whitelist request; it would require much greater review to ensure that we are not causing issues for other customers. In this case whitelisting would mean we pull in the package and all of the related dependencies (for all customers).
In this case Microsoft.PowerBI.Api is a wrapper for APIs, and the code for it is MIT and available on GitHub. You should be able to pull in any code needed to use at the project level vs us pulling in an additional nuget library.
Can you help us understand what challenges or issues might be preventing you from using the current approach?