I've a very basic question to clarify the difference of depiction of Phone field at the form of accounts and in the view/advanced find/data import matched fields.
Actually, the label of the field is set to Phone but its display name is Main Phone.
An attribute's Display Name is the name that will show up in Advanced Find and Views. You can override this Display Name in the Form by double-clicking on the attribute to bring up the Properties window.
As you've seen, it can be confusing for users if the attribute is called one thing on the form and another thing in views and Advanced Find. I recommend keeping them the same unless there is a good reason not to.
Related
I'm passing a parameter to a PowerApp through the calling URL called ID, i.e.
https://web.powerapps.com/apps/powerappid?ID=32
When the app launches I want it to jump from BrowseScreen1 which lists all the Business Cases and go straight to the Business Case with the matching ID (a field from a SharePoint list).
I'm brand new to PowerApps but pretty sure what I need to do is called Deep Linking and I found this tutorial https://powerapps.microsoft.com/en-us/blog/powerapps-deep-linking/ and having read the comments to the article I'm trying to apply it to the OnStart property of BrowseScreen1. I don't really understand how the navigation link in the tutorial is constructed so I'm sure I'm using the wrong Navigation parameters as it always launches the first record in the list ignoring anything to do with the ID. I'm using:
If(Not(IsBlank(Param("ID"))),Navigate(DetailScreen1,
None,{ID:LookUp('Full Business Case For Review'.ID, ID =
Value(Param("ID")))}))
'Full Business Case For Review' is the name of the Sharepoint list and ID is a unique field that gets assigned to each list item.
The tutorial doesn't mention having to change anything on the detail screen but I've also wondered if I need to perhaps change the item properties there as they are currently:
BrowseGallery1.Selected
I'm feeling out of my depth and would really appreciate some help on this!
Thanks,
John
Yes, you need to change the Item property in the detail screen. This is because there is currently no way to select an item in a gallery programmatically in PowerApps.
I normally get around this by using a global variable to store the current item, so you can set BrowseSreen1.OnStart to this
If(Not(IsBlank(Param("ID"))),
Set(CurrentItem, LookUp('Full Business Case For Review'.ID, ID = Value(Param("ID"))));
Navigate(DetailScreen1, None)
)
This will store the item with ID equal to your parameter as a record type variable.
You also need to change the OnSelect property of your BrowseGallery1's template or whichever control is used to navigate to the detail screen. It will need to be something like this
Set(CurrentItem, ThisItem); Navigate(DetailScreen1, None)
Finally set the Item property in the detail screen simply to this
CurrentItem
I customize the campaign form and i face the some problem
1.How to customize the name "GENERAL".i need the name instead of GENERAL .Where to change?or which property should i change?
2.cant delete Lock symbol fields if we try , its saying "It is allowed only for business units".How to unlock and How to delete this?
As Guido suggests, double you can edit the name of the tab by opening up the form in the form editor, double clicking on the tab, and changing the label.
As far as the locked field, you'll have to mark the field as not required, in the entity customization, publish your changes, then you can delete the field from the form.
The label for any tab can be changed by the form editor, if you want a dynamic value you can set using supported customization as this example:
var firstTab = Xrm.Page.ui.tabs.get(0);
firstTab.setLabel("new tab name");
If a field is locked, it means that is business required (in your case is the name of the campaign that must be filled), you can always hide the field and pre-fill the value using javascript code inside onload, onchange or onsave events.
Perhaps someone else can suggest a better (i.e. supported) solution but until then - why not find out the id of those elements and edit them directly from JS in onload? Let me repeat, though, that such an operation is unsupported.
In my SharePoint List, I have an "Employee" column that is a User type field. I would like to add some custom Business Logic to the processing of this field.
Currently, when the user adds a row, I check to see if the user is an Employee or a Manager and then change the behavior on this column accordingly. I do this by statically rendering the field in my custom "ListForm Rendering Template", just before my custom ListFieldIterator. I simply use a standard SharePoint FormField (and FormLabel) control. In the markup of the FormField control, I specify the FieldName (Employee) and an event handler for the Load event. In this Load event, I will check to see if the current user is an Employee or Manager (using two different SharePoint groups). If the user is an Employee I set the value of the field to the current user (this part works perfectly). I also want to change the field so it can't be modified. I thought I might be able to just change the ControlMode on the field (in the code of the OnLoad Event Handler) to Display, but for some reason this has no effect. The field still renders with the full, people picker editor. Am I not changing the fields control mode soon enough? Or is this simply not the correct approach? The other logic I want to put in is if the user is a Manager, I would like to allow that user to select the person from a list (SharePoint group) of Employees. It may be easier to just use the people picker and limit the selectable users to that group. (I think I can do this with the SelectionGroup property.) Although, it would be better if I could just provide a dropdownlist of users, which I could possibly do with a hidden dropdownlist that I would show and event handlers that I could use (handle event selectedindexchanged) to pull the value selected and populate the (now hidden) Employee (user) field. Does this approach make sense? Assuming all that will work, the real difficulty I am having is with changing the ControlMode (rendering) on the field (when the user is an employee) to a label or some kind of read only control, which is how that field renders when viewing the row, which is why I think if I can just trick the control into thinking it is in Display mode then it should work perfectly!
I am still learning SharePoint, but I am very proficient in ASP .Net. This is why I would like to keep my customizations in this Custom Rendering Template, using code behind and leverage my existing skill set as much as properly.
Any thoughts, opinions or advice? Does anyone know why I can't get the column to switch the "Control Mode"?
I do not think that I fully understand your scenario. Some code samples could help.
But anyway it sounds like you want some heavy customizations of the user field. In that case you might want to have a look at creating a custom field with all its advantages and disadvantages. Have a look at MSDN: http://msdn.microsoft.com/en-us/library/gg132914.aspx
Another option might be - in case you do not want to re-use this column in many list definitions - that you can get away with your custom rendering template and create a custom create/edit form where you implement the specific edit behaviour for the field (plain ASP.NET with some SharePoint controls). Here is a nice walk-through on how to grab a custom edit form from SharePoint designer: http://community.bamboosolutions.com/blogs/sharepoint-2010/archive/2011/05/12/sharepoint-2010-cookbook-how-to-create-a-customized-list-edit-form-for-development-in-visual-studio-2010.aspx
I hope this helps. Kr., Bernd.
I have a SharePoint list that has MANY columns in it. The default AddForm and EditForm rendering is very cumbersome for the users. Most of these fields hold simple Number (integer) values. The default rendering for those two forms (using the ListFieldIterator I suppose) render the columns one by one vertically down the page. My thought was to design an input form with three basic "zones" (left/middle/right) and use a Custom Field for all of these "Number" fields. The Custom Field would contain two custom variable properties "Zone" and "Order". (Zone could contain middle/right and order would be the "order" in that zone the field would appear, the "left" zone would be for the fields that are not these "Number" fields, things like Date, Customer, etc. etc.) I would design the page with an HTML table and 6 Columns (1 for the "label" and one for the "TextBox" for each of the three "zones"). Then I could put a control (something similar to the "ListFieldIterator"). The control in the first zone would render the "static" fields, the zones in the other two zones would render the appropriate Custom Fields (based on the Custom Variable Property "Zone" and "Order").
Does this make sense? For the life of me, I can't figure out how to do this. I had thought about "giving up" and just using my ASP .Net skillset and creating FormViews and GridViews bound to the proper (ListView) DataSources. That has even proved challenging.
Does anyone have any ideas on how I could accomplish this? (InfoPath isn't an option and I want to stay with the "Custom Field" idea so the fields aren't laid out statically and can be moved around or even new ones added by the "administrator" of the Application (SharePoint List).
Any guidance is MUCH appreciated. I have been working on this all week and just seem "stuck".
Thanks,
Shayne
------ A Better explanation of my "application" and what I want to do-----
I have a SharePoint List that has about 60 fields in it. If I pushed this application out using the default Add/Edit SharePoint List Forms (and Rendering Templates), the users would hate it. The default forms use a rendering template that basically lays out all the list fields, one per (HTML) Row. Within that Row there are two (HTML) columns. The first one contains the "Label" for the field, and the second (HTML) column is the actual editor for the "FormField" (Text Box or whatever). Because of the number of fields in the list, the user would have to scroll several pages just to get to the bottom.
This list has about 10 "static fields" that I want to lay out on the left side of the page and then about 50 that are simply "task" fields. These store an integer and track "how many of these tasks did I do today". (This is a "port" of an MS Access application.) Depending on the "Add" page the user selects (I have a "parent" content type that contains every field and then a "child" content type for each "group" of users that will be using this form that contains just the fields/tasks that group tracks) the proper fields are rendered on the page. The problem is they are all rendered vertically and there is too much scrolling. These users (and admins) will NOT have access to SharePoint Designer or InfoPath. So, the "layout" for these fields must be iterator/repeater style (the users shouldn't have to get Development involved just to add a new "task" field to their application!).
The solution I had come up with is to use a Custom Field Type with two Custom Property Variables for each of these "task" fields. The Custom Property Variables (Zone and Order) would allow the administrators of the "application" to control where they want these fields to appear on the Add and Edit forms. The Zone Property can contain one of two values: "1st Task Column" (middle of the form) or "2nd Task Column" (right part of the form). (The "left" column of the forms would be used for those 10 or so "static" fields that all groups/depts/content types share.)The Order would just contain the order to sort the fields in, within their "zone". Obviously, the "zone" would indicate where on the form the field would appear (middle or right). I thought I might be able to use three Divs and render the appropriate List Columns in the appropriate DIVS. Or, following the default rendering template, instad of DIVs I could possibly use 6 (HTML) Columns instead of 2.
I quickly figured out how to make a new Field Type with Custom Properties (I used the Property Schema element in the XML definition, even though Microsoft says NOT to use that in SharePoint 2010, it was just so easy and I couldn't figure out how to add them otherwise. Now I know how to add them the "right" way, I just don't know if it is worth changing them.)
For the last few days, I have tried to figure out how to actually render these "zones". Remember, I want the users of this application to be able to add new fields dynamically, so I can't put any static field references in these forms. I have read about the Rendering Templates and the ListFieldIterator (and the new Content Iterator), but I can't seem to pull it all together and create an actual solution. The part that is throwing me off is how to query and render three different "sets" of fields at once (since the rendering is going to happen from "top to bottom").
Any help is very much appreciated!
Shayne
If InfoPath it out and you want to stay within the SharePoint infrastructure for forms, then the term you need to search for is DataFormWebPart. You may have heard of DataViewWebPart before, well this is the form equivalent. Just like the DVWP, this does lots and lots of XSLT to make its magic happen.
The trick is can you implement your grid/zone idea within the context of the DFWP's XSL. That I can't tell you but hopefully this is a starting point.
Defiantly Info Path is the solution here are some tutorials:
Video: http://channel9.msdn.com/blogs/laurhar/infopath-2010-customize-a-sharepoint-list-form
http://p2p.wrox.com/content/articles/customizing-sharepoint-2010-list-forms-infopath-2010
http://blog.libinuko.com/2010/03/21/sharepoint-2010-howto-start-customize-list-form-neweditview-using-infopath-designer-2010/
if you don't want to use InfoPath I would recomment JavaScript/jQuery you have just to modify (Edit) the page then inject some jQuery code to do what you want. Here are some articles about similar topics:
http://akanoongo.blogspot.com/2008/04/how-to-hide-fields-in-sharepoint-list.html
http://spground0.blogspot.com/2011/03/sharepoint-2010-custom-list-form-issues.html
http://ghamson.wordpress.com/2011/01/19/using-jquery-to-attach-regular-expression-validation-to-a-sharepoint-list-form-field-sp2010-ps2010-projectserver-in/
The only way you can achieve this type of custom form designing within the SharePoint framework is to apply it through post-rendering techniques using client-side code. And solutions like this tend to add considerably to page-load.
Simply changing the render template is not enough if you want it to be a dynamic and codeless experience for end users to author.
I can think of only one solution which comes close to fitting all criteria. It's "free", can be password protected, and also allows tab groups, rules and many other settings.
Dynamic Forms For SharePoint - http://spjsblog.com/dffs
I was going through honeybots and found out something which took me by surprise..
"Honeypot fields are invisible fields on the form. Invisible is different than hidden. Hidden is a type of field that is not displayed for editing. Bots understand hidden fields, because hidden fields often carry identifying information that has to be returned intact. Invisible fields are ordinary editable fields that have been made invisible in the browser..."
if honeybots are invisible, how is that such fields are editable.. moreover is it that it helps us acheive some security.. how is that?
If a field is moved out of the render window via CSS, the bot wouldn't know it (because it ignores CSS). A human user won't fill in the field, a bot will.
You can hide a regular form field, such as a text box or textarea with some simple CSS. If it has been hidden like this human users using a browser can't add any data to it, programatically it can still be added to though, by a bot, and they will likely add data to all available fields. So if field is not empty it must have been submitted by a bot.
Here is an nice lecture with some good examples:
How to fight guestbook spam
However...Honeybots are prepared fields which lead the bot which is trying to use the formular in a trap. From my point of view this fields are called "invisible" cause the Bot cannot get the main purpose of that field.