When using the Microsoft Office URI Schemes as a link to a document in a SharePoint Library (e.g. ms-word:ofv|u|http://server/site/library/file.docx), the browser client opens the document directly from SharePoint using the specified Office program (tested on SharePoint 2016). This avoids the default behavior of downloading documents locally, saving changes locally and then being forced to upload documents back into SharePoint when using regular "http" hyperlinks.

I'd like to request that the SmartForms Hyperlink control be updated to support Microsoft Office URI Schemes in the URL property. Currently it does not allow input of URLs using Microsoft Office URI Schemes. Though a workaround is possible by first setting an expression to contain the URI command and then setting the Hyperlink control's URL property to this expression, it's less than ideal.

Considering, SmartRules would have the following type of variables:

• Input parameters
• Data fields/Variables (to be used as temp data storage for example to transform, transfer and calculate data, etc.) So, data which is only available during rule execution.
• Output parameters

With SmartRules you would have the ability to:

• Create your own library of reusable business rules and use them in other views, forms or workflows to avoid creating the same rules for every Form and Workflow
• Run client side or server side
• Make them available as an expression
• Combining output of multiple SmartObjects
• Available in the Category Browser

SmartRules should have conditions like:

1. If Conditions (Comparisons with Input parameters, Data fields/variables, Output parameters)
2. Nested conditions
3. Exception handlers (error handling/error occurred)
4. For each conditions
5. Switch conditions

and should have actions like:

1. SmartObject executions
2. Transfer Data
3. Execute another rule
4. Showing a message
5. Running some Javascript
6. Sending an Email
7. Navigate to a form or URL
8. SubView/SubForm interactions
9. Closing the browser
10. Workflow interactions (start, open, action (SN required))
11. Stop rule execution
12. Continue to next execution

With SmartRules, there are no specific defined interactions with controls, views and other K2 elements due to re-usability. Those rules should still be used inside Views and Forms. With SmartRules you interact with predefined Parameters or SmartObjects executions. SmartObject outputs can be transferred to parameters and parameters can be used as input/filter for SmartObjects.

So SmartRules are like unbound rules but then more flexible for faster developing, avoiding SQL stored procedures and avoiding duplicate rules.

Please write down your comments below about is idea. Let me know if I missed something or if you have better ideas!

And last but not least:

Promote and VOTE this idea within your organization to push it on top of the trending page!

This Idea in combination with the ability to copy and paste rules, would be very nice as well!: https://ideas.k2.com/ideas/APIT-I-106

I'd like to suggest a different kind of list view where every row is in the Inline Editing mode instead of the default Display mode. But unlike the current inline editing mode's layout, the rows would not be restricted to one field per column. Instead every row would be in essence be a repeated item view, allowing full flexibility in control layout.

For example a form can consist of rows where there's a label control and to the right would be a drop down ON TOP of a text area. And this is repeated 10 times. Instead of adding 10 label objects, 10 drop downs, and 10 text areas, this new kind of list view would be used to repeat these objects.

Benefits would include:

• users not required to "activate" the row to be able to edit

• display as much data as desired in a row without concern for overly-narrow column widths

• display data in a consistent layout instead of jumping between the current "Display" mode and "Edit" mode

It would be so helpfull if there was a standard control that would let you edit list items as if it were an excel (like a table):

Some basic functional requirements would be:

• A user is able to edit a specific cell in a line (row) by simply clicking on that cell
• A user is able to jump between lines (rows), without losing the focus of the cell (column) they've selected
• A user is able to jump between cells (columns) and lines (rows) by the keyboard e.g. using tab and arrow keys (like excel)
• A line is saved when a cell on the line has changed and the line is no longer being edited
• A cell within a line can be of different control types (e.g. textbox, dropdown, lookup, autocomplete).
• A cell has validation based on the control type and specified value