I've created a Task List in my app web with a custom content type based on task. I want to be have an email sent when an item is assigned to someone.
Looking around it seems that adding EmailAssignTo="TRUE" to the List element in Schema.xml should do the trick however I see the following:
Warning 1 The 'EmailAssignTo' attribute is not declared.
EmailAssignTo doesn't seem to be documented by Microsoft. Am I going about this the wrong way?
Based on a quick PowerShell check/test the List property you want appears to be entitled EnableAssignToEmail, which expects a Boolean value.
Source documentation from MSDN:
https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.splist.enableassigntoemail.aspx
SPList.EnableAssignToEmail property
Gets or sets a Boolean value specifying whether e-mail notification is enabled for the list.
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
In SharePoint Online, I have a SharePoint Designer 2013 List workflow. The workflow can be started manually without any problems (I am starting it on a custom Documentset content type called "ServiceOrder").
When I set the workflow to start automatically when a "ServiceOrder" content-type item is created. The workflow terminates instantly.
Details: The values provided for the root activity's arguments did not satisfy the root
activity's requirements: 'DynamicActivity': Expected an input parameter value of type
'System.String' for parameter named 'UniqueId'. Parameter name: rootArgumentValues
I have created another simple workflow just to check if's able to start automatically, and the new simple workflow does start automatically.
Finally I understood what the error was.
I have created a variable named "UniqueId", which represents the items UniqueId (Guid). I'm using this variable in a REST call to "GetFolderById".
After I changed that variable name to UniqueGUID, everything worked.
Seemed like a reserved variablename needed to initiate some Azure automation etc.
I'm using Visual Studio 2012 to create a custom Site Column of type TaxonomyFieldType, a custom content type that uses it, and a custom list that uses the content type.
Everything appears to deploy fine. If I look at my custom site column it appears to reference the proper termset correctly. I can create a new list in the web UI that uses my custom content type just fine. However, my custom list created using the Visual Studio 2012 List template always shows my taxonomy field as disabled on the new form. Here are the other things I've witnessed about it:
In the web UI of SharePoint, if I go to the list properties and drill into my taxonomy site column I notice it shows that it isn't mapped to a termset. Keep in mind that if I do the same thing in Site Settings for my content type it appears correct. I can do the same thing for the web UI created custom list and everything is fine (editable in the new form and the field has the termset defined).
If I use powershell to dump out the info for the site column itself it has a valid termset.
If I use powershell to dump out the info for the field in the VS2012 created list it shows emtpy guid for the SspId, TermSetId, and TextField. It also shows IsTermSetValid = False.
If I use powershell to dump out the info for the field in the SharePoint web UI created list it shows the correct guid for the SspId, TermSetId, and TextField. It also shows IsTermSetValid = True.
Does anyone know why I seem to be having this behavior for the VS 2012 create custom list? Any help is appreciated.
Okay, so I'm going to answer my own question. Hopefully this will help someone else in the future.
My issue was that when creating a sample list for my content type (described in original question post), using the SharePoint UI, the needed Note field was getting added. Even if I had this right in my original TaxonomyFieldType declaration, I would have also ran into issues with my field values not showing up in the search refiners later on when I got to that part. Thankfully Ari Bakker has written a very detail explanation of what all you need to do in order to create your custom TaxonomyFieldType derived field, a custom content type to use it, a list definition, and a list instance. Just follow the details in the article: http://www.sharepointconfig.com/2011/03/the-complete-guide-to-provisioning-sharepoint-2010-managed-metadata-fields/
I'm working on a SharePoint publishing site and I want to "log" all the changes made by users in a SharePoint list.
Some searches on the web guided me to the EventReceiver.
But my EventReceiver must be generic and attached to all lists in the site collection. The "log list" has several columns like the name of the list in which the event occurred, the name of the modified item, its old value and its new value.
Can someone guides me on how to achieve this?
There's already a provided answer for you on StackOverflow, hurrayy!!
It sounds possible. Create a class that inherits from SPItemEventReceiver and override ItemUpdating. You can use the following code to get the list:
using (SPWeb web = properties.OpenWeb())
{
SPList list = web.Lists[properties.ListId];
}
You can then use list to grab the list's title and URL. Next, compare each DictionaryEntry entry in properties.AfterProperties to the corresponding value in properties.ListItem to get your differences. Then save it to your log list. The trick would be automatically attaching your Event Receiver to each newly created list. Perhaps a timer job would work.
That said...
Before trying any of that, go to your site collection's Site Settings. Under Site Collection Administration, click Site collection audit settings. Under Specify the Document and Item events to audit, check Editing items. Only go with a custom solution if that does not give you what you need.
Would Version history not achieve the same functionality?
You can see what fields were changed by who and when. Though you would have to look at a list by list basis.
You can also access the version history information via the object model if you want to generate reports web part.
Otherwise using Janis Veinbergs link on how to attach a event handler to all lists and Rich Bennema method of getting the values from the updated item in a generic way, though I would use ItemUpdated as you don’t want to change the data that was updated only copy it to another location so there is no need to catch the data before it is submitted to the SharePoint database
I'm trying to figure out a clean way to hide a custom field type from the list of available columns when a user goes to add a new column to a list. I only want this field type to show up when a given feature has been activated (the feature could be site, web, or web app scoped for my purposes).
One theory (haven't had a chance to try implementing this yet) is that I could set all the ShowOnListAuthoringPages (and similar) properties to "false" in the fldtypes_myfield.xml file, then programmatically set this value to true when a given feature is activated.
In XML file, please set
<Field Name="UserCreatable">FALSE</Field>
I't work with me
Are you sure that you are able to see the Publishing Fields Type in the List Create Column Only with Publishing Infrastructure feature activated. I have a MOSS 2007 Server and I Create a Site Collection based on the Team Site (In this Publishing Infrastructure was not active) but still I was able to see the Rich HTML Fields in the Create Site Column Page. I doubt Publishing Infrastructure controls this function. Your option is good one for this, I would say.
Custom Field Types Features are per definition Farm Scoped, since Custom Field Types have to be deployed farm wide.
You cannot "hide" them from users. A field in a list is based on a field type (bool, user etc.). You CAN hide fields, not the base types. So if a user wishes to create an entirely new (site) column, he or she 'll be able to see that field type.
So, it does look like the only way to do really hide the field times is with attributes in the fldtypes_myfield.xml file. There are a series of properties that affect it's visibility described in this MSDN page. In my particular case I ended up just using the UserCreatable property and marking it as false. This pretty much means the field type won't show up in the UI anywhere, so you'll need to make a feature or some kind of list/library template that you deploy that makes use of the type. I guess this is an area we can hope for improvement on in SP 2010 (perhaps along with a scoping mechanism for event receivers so they don't have to be "global" in the farm).