Nintex Automation K2: Back to basics
Access resources, discussions, and troubleshooting tips to build custom applications and streamline workflows with Skuid NLX, SFX, & EXP.
Recently active
Not sure if many of you regularly deploy VF pages with the skuid:page component to new orgs. One of the problems we run into is that the skuid version in the meta-data of a VF page is the whatever version was active when the page was created. So, if you create a page on skuid 7.31 in one org, and you have a new org where the first version of skuid is 7.36, you get an error when you try to deploy the VF page to the new org. The specified version of the package doesn’t exist. Since you can’t install the older version of skuid, you have to update the skuid version in the page’s metadata before you deploy. Which is a pain if you have a lot of pages. Or was a pain, until grunt. You can update the metadata for all your VF pages with grunt, using grunt-string-replace, like so: 'string-replace': { skuidversionupdate: { files: [{ expand: true, cwd: 'src/pages/', src: '*.page-meta.xml', dest: 'src/pages/' }], options: {
I find myself constantly writing a field template to ensure that a non-Name field gets hyperlinked to the Id of the record. This approach has its shortcomings and also required customized HTML, etc.Would like to see support added to a component field to “treat” it as a nameField whereby the field in read/readonly mode woulda automatically be wrapped in a hyperlink to the Id of the record. This would behave exactly the way the “Name” field does today, just be configurable to apply to any field. I could see this working as a field metadata override (preferred so that you only need to do it in once place) as well as a component field option.Several different options for achieving this behavior, but adding a declaritive option would greatly simplify the experience and avoid requiring HTML or JS.Use Case - All of our “Name” fields in our custom objects are auto-numbers and we use an SObject specific field for the “Name” (e.g. it might be called Description__c, it might be called Code__c,
This has been discussed in various threads but I couldn’t find a specific post requesting this feature. Apologize if it’s a duplicate.Currently, Skuid provides support for many formula functions. Unfortunately, there are often specific application needs or even just general use cases for formula features that aren’t offered by the core product.Would like to see support added for registering custom formulas.Examples of what I’ve needed and added (unsupported currently of course):1) register ISNEWID(rowId)2) register ISEXISTINGID(rowId)3) register ISROWUNSAVEDCLONE(modelName, rowId)4) register FORMAT_NUMBER(value, format)5) register FORMAT_FIELD(modelId, fieldId, value)6) register UPPER(value)7) register LOWER(value)8) register LENGTH(value)…and several othersThank you!
Currently, Skuid provides support in merge syntax for things like $Model, $Label, etc. as well as some stock functions like en/decodeUrl. Would like to see support added for registering custom merge/mustache properties and functions.Examples:1) register $MyAppInfo which is an in-memory objectUsage: {{$MyAppInfo.myProperty}}2) register currentTime which would be a function to automatically merge in the current timeUsage: {{#currentTime}}The time is: {{/currentTime}}3) register doSomethingCool which would be a function to automatically merge in something coolUsage: {{#doSomethingCool}}{{MyField__c}}{{/doSomethingCool}}Thank you!
This is a question but I think it’s an idea too. We have a chart and a table showing similar data a bunch of records with category and subcategory fields. The chart has columns with number of records per category, and the table shows all the records. When you click a column it drills down to a chart of all the records for that category grouped by subcategory. It also filters the table. We now need to figure out how to get the table to filter yet again when the Back button is pressed, or rather to un-filter. When you click Back, table stays to where it’s just showing records from one category instead of again showing all records from all categories. I think we could do this if we reworked our chart and table to use the same model, but is there another way? If not, I’m proposing an idea to Add Actions to Chart Back Button.
This has been talked about before but not sure where it stands.Would like to see merge syntax supported for a Model condition set to Specific (or Multiple) values. While unlikely to occur, to avoid any possible regressions in this field a new property on the condition could be provided to “Apply Merge Syntax” or something of that nature.Being able to use merge syntax in this field would give it consistancy with other features (e.g. Active & Set Model Condition) and also provide a means to leverage the condition in other areas (table filters).
Automatic filters are extremely handy and avoid a lot of extra declaritive configuration that would otherwise be necessary.Would like to see a way to configure a default value for the filter so that it is applied on page load.For example, use an Automatic Filter to filter Accounts based on OwnerId where the default filter value on page load is the current $User.userId
We quietly switched over to our new skuid.com domain this week. All old skuidify.com links will continue to work, so visitors to our site should not experience any problems. If any of you have been through the process of switching domains, you will be familiar with the complexity of such an undertaking. And as if that weren’t enough, we also added SSL to all subdomains on the skuid.com domain! I’m summoning you, our faithful Skuid community, to check it out… Let me know if you find something buggy related to these changes. You can email me at joseph@skuid.com or just leave a comment below. (And yes, email addresses for all of us are now @skuid.com, but mail sent to @skuidify.com addresses will still get to us.)
Currently there is the ability to display a message and block the UI as an action. It would be nice to have the ability to have an “OK/Cancel” message that would block the UI, display a message, then give the user the option of clicking OK or Cancel. For example: “Are you sure you want to commit these changes to all 140 Contacts?” OK or CANCEL. If the user presses Cancel, it would abort any actions after the OK/Cancel Message Action
We like queues with drawers to categorize queue items. For top-level queues where the only on-click action is open/close drawer, here’s two simple one-line snippets we’re using to expand and collapse all: expand: skuid.$('#CategoryQueue').find('.nx-list-contents:first').children('.nx-queue-item').not('.nx-item-has-drawer').click(); collapse: skuid.$('#CategoryQueue').find('.nx-list-contents:first').children('.nx-item-has-drawer').click();
Ever had to type 1 AND 2 AND 3 AND 4 AND 5 AND (6 OR 7)?Would be great to be to do 1 THROUGH 5 AND (6 OR 7)Even better would be 1-5 AND (6 OR 7).Small thing but should be easy to do.
Would like to see the ability to assign a uniqueid and cssclass to table column headers. Beyond just making styling column headers easier, since conditional columns is not possible, having a way to identify column headers would provide a hook to programmatically show/hide columns.Thank you!
Couple of ideas for enhancements to component messages (e.g. errors);1) Currently, clicking a message removes it from the DOM. The challenge with this is that often times users wants to copy/paste the message text but are unable to because the message dissappears as soon as you click on it. Would like to see an “x” icon on the right side of the message for dismissing and the click handler removed so that the message remains displayed unless you click the ‘x’. Additionally, there could be a “dismiss all” feature for quick dismissal of all messages.2) Would like to see a feature added for customizing messages. This would require the full details of the message (e.g. field, row, etc.) be provided so that the message could be customized. I could see this working as either an overriden “formatMessage” method or some type of callback. There is a post at https://community.skuid.com/t/how-to-obtaining-raw-error-messages-returned-from-model-ope… which discusses obtaining the full error de
tabshow event has a property called “timeStamp”What’s up with the camel case? timestamp is one word!I’m just joking around, but my failure to look closely at the event properties and notice the camel case did cost me 5 minutes of confusion.
A simple idea:When we click the “create model” button, the default “NewModel” text in the model id should be automatically selected so we can just start typing the model’s name without clicking on the field.
For those who don’t know me, I’m the Director of User Experience here at Skuid. I’m doing a some user research and I could use about 10 participants.It’s painless (I think) and will take about 10-15 minutes of your time. All you need is a web browser.If you’re interested, send me an email and I’ll send you the link. I’m shannon at skuid.com!I’ll accept participants until Friday, April 8th, 2016 or until I get 10 sign-ups - whichever comes first. (I’d like to limit it to one person per organization initially, so I get a range of people.)Thanks for participating in our community, and helping us make Skuid better!
Would like to see the following enhancements for Queues:1) Update “Panel” - This would be a combination of the drawer concept and update page include concept. In short, instead of expanding a drawer below the queue item, allow for designating a “panel” where the contents are displayed. While useful, drawers are rather cumbersome when navigating lots of records (table or queue). The drawer functionality is great, just would like to be able to target where the drawer should go. Page includes are also useful in their own right, but when dealing with “lists” and “details about list items”, handling navigation, model changes, etc. between the parent page and the include page is challenging. an “Update Panel” action would bring both of these concepts together.2) Add global actions - Akin to table global actions3) Add row actions - Akin to table row actionsHere’s a demo of all 3 concepts:
Currently, to use the FORMAT_DATE function, you must specify the format to use. In a globalized application, date/time formats are not always the same.Would like to see support added for the following:1) FORMAT_LOCALEDATE(date) function2) FORMAT_LOCALEDATETIME(date) function3) Expore skuid.utils.userLocale in Global merge variablesThank you!
Hey Skuid friends! As you think about increased accessibility it would be great for the date-selector field type to respond to keyboard arrows. Right now if you click “enter” it selects today’s date, which is great. It would be awesome if you could also navigate around the little calendar with the keyboard arrows, to easily select days like “tomorrow” “yesterday” and “one week from today”Thanks!
With the new in-line field errors, it would be nice to be able to disable visiblity to error messages in the page title (and any other initiating component).Adding something like a “Do not show errors” property would do the trick.Thanks!
Custom Action support has been talked about for a long time (here, here, here and others). About 1.5 years ago, in this post, it was mentioned that custom actions are exposed for custom components although as far as I know, it still has yet to be documented how to officially accomplish this. Encountering the need for this constantly lately, I decided to dig in to see what could be done. Below is a demo of what that functionality might look like and how powerful it could be. I think we’d all agree that Skuid is awesome. Unfortunately, as great as the team is, they cannot possibly keep up with all “features” that Skuid customers/partners want and need. To me, the most important “feature” Skuid can add is the “extensibility feature” - e.g. custom actions, custom conditions, etc. Armed with the ability to extend, Skuid customers (and in turn, Skuid itself) can truly realize the full potential of this amazing product. In short, the possibilities would be endless.Skuid - Can you let us
As per these types:
Probably not possible, but just in case someone found a way…Now that we are using skuid, I have no more utility for SF Standard sidebar , except for 1 crucial ItemOur Dialer (CTI) in part of the sidebar and we need to keep it open for call disposition…Would there be any way to have it directly in a skuid page, thus allowing us to completely stay away from it being open at all times?Thank you
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.