I’ll keep it short and sweet. Does anyone really know what the "ListTemplateOwner" tag of the elements.xml's "Receivers" node really means?
From Microsoft’s site: http://msdn.microsoft.com/en-us/library/ms431081(loband).aspx
ListTemplateOwner: Optional Text. Specifies the GUID of the list template owner if the list template is registered via Features, or the name of the site definition if the list template is registered by a site definition.
If the list is defined by a ListTemplate in a Feature then ListTemplateOwner is the ID of the feature that defined the list.
When you're refering to any of the standard lists (with ListTemplateId < 10000) then you don't need to specify a ListTemplateOwner (due to backwards compability)
When you're refering to a list that's defined by you or a third party, then you need the combination of ListTemplateId (> 10000 and matching the Type attribute from the defining ListTemplate) and ListTemplateOwner matching the FeatureId of the feature that defined the ListTemplate.
This is due to the fact that when you define a ListTemplate the rule is that Type should be > 10000 and unique inside the feature, but any number of feature may have their own ListTemplate with type 10001 (and feature which define lists usually just start from 10001)
If the list is defined by a ListTemplate in a Site definition then ListTemplateOwner is the name of that Site Definition, but don't define lists in Site definitions do it in features.
This is not correct, the feature ID when set to the current feature, which contains the list definition for the list type, does not target the reciever correctly...
<ListTemplate
Name="SomeList"
Type="99002"
BaseType="0"
OnQuickLaunch="TRUE"
SecurityBits="11"
Sequence="410"
DisplayName="Some List"
Description="Custom List used for whatnot"
Image="/_layouts/images/itgen.gif"/>
<Receivers ListTemplateId="99002" ListTemplateOwner="B1E4631D-52A1-48d0-A319-2DDC2893AA57">
What you need to do is give each List Template a unique ID, regardless of the owning feature.
I am guessing that it refers to the ID (GUID) of the SharePoint object that owns the list template. Think of it like the ID column of a database and this would be it's foreign key.
Related
I wanted to add an extension in backoffice, so that it is possible for non-programming people to add new objects (of defined types) to the database.
I've almost done it:
I defined two items: offer and tile (their relation is one to many)
What i achieved is there is a possibility to add a new offer in the backoffice.
When you add it, and click to edit, you can also add a tile to this offer - either form drop-down list (if any tiles exist) or create a new tile, which will automatically be added to its table and realted to edited offer.
However, the representation of the drop-down list is unacceptable, see below:
screenshot from backoffice
as you can see, the identifier of an existing tile (within []) is its PK - which clearly is not a good identifier. I would like to inject there instead a value form one of tile's other attributes (which also is unique) so that someone could easily identify which tile to add.
Where is the mechanism responsible for it? How to override it. I tried to override toString method in the tile class, unfortunately to no avail
You need to customize the backoffice-config.xml for your custom Model. For your Tile model, you can use something like:
<context merge-by="type" type="Tile" component="base">
<y:base xmlns:y="http://www.hybris.com/cockpit/config/hybris">
<y:labels>
<y:label>nameOfTile</y:label>
</y:labels>
</y:base>
</context>
I have an odd issue.
I have client that wants a sharepoint list what is populated from a WCFService. That part is working quite well.
I have a bdcmodel that is mapping the WCF data and I can create an external list from the bdcmodel as well so that is working fine.
The issue I have is that one of the properties in the model is actually a collection of entities called Attributes. The objects in this collection simply have 2 properties Name and Value so really they are just a key value pair.
The client wants to see the list of attributes of the parent entity in the external list. So there would be an Attributes column and within that column would be the list of attributes for each parent object.
Is there even a way to do this? I am looking into Custom Field Types, but it seems like these are really intended to be singular values.
How would I create a list within and external list?
Any help anyone can give would be great even if its just to tell me that there really isn't a stable way to do this so I can go back to the client and tell them we will need to build a custom list to support this because the OOB external list and custom fields and custom field types won't support this kind of nested listing.
I decided to set up the custom field as a string and when I get my collection in from the BdcModel I am serializing it to JSON and then passing it to the field. When the field is viewed in display, edit or new I have overridden the FieldRenderingControl and I am tiling the collection out that way.
Trying to do something with OpenLDAP that should be very simple, just can't seem to find a clear answer. I need to be able to organize any person's contact attributes according to their "type". For example, email would be type 6. So, if I wanted to send an email to all members of my OU, I would choose those that have a type 6 address.
since LDAP attributes are a name, value pair, I don't see how to assign an additional property to a contact address, yet it seems like a common enough problem. Any suggestions?
Attributes in the directory server model are indeed name [optional option] value constructs. To accomplish the task you describe, you could assign another attribute to the entry. RFC2798 defines the employeeType (link) attribute type with a syntax of DirectoryString and an equality matching rule of caseIgnoreMatch. Perhaps this attribute could be used for your purposes. If you assigned the attribute like:
employeeType: type 6
the LDAP client would then find all those employees with a filter like
(&(employeeType=type 6)(objectClass=inetOrgPerson)).
If you had concerns about the matching being caseIgnoreMatch you could specify that the server use caseExactMatch by using an extensible match filter like:
(&(employeeType:caseExactMatch:=type 6)(objectClass=inetOrgPerson))
employeeType is multi-valued, therefore, employees could have more than one employeeType. Any value that is a valid DirectoryString could be assigned to employeeType.
I try to add lookup field in content type. Field has this definition:
<Field ID="{c80e8e3c-7124-4772-a39d-5b69f131d542}"
Name="Site"
Group="Tieto Intranet Columns"
Type="Lookup"
DisplayName="Site"
StaticName="Site"
List="Lists/FavoriteSites"
ShowField="Title"
PrependId="TRUE"
WebId="~sitecollection"
>
FavoriteSites list, which I want reference by this lookup field, exists on the site collection scope. Deployment goes fine, but when I create list based on content type with this lookup it looks like that lookup field is not connected to FavoriteSites list. I add some data into FavoriteSites and than I a try to add something into second list with lookup field on FavoriteSites. Unfortunately drop down select, which should show me data from FavoriteSites list is empty.
When I create new lookup column to FavoriteSites manually everything is OK.
Do anybody have some idea where can be problem in this lookup definition?
UPDATE:
As Rich recommended me, I set log level on Verbose a find this message:
The WebId=~sitecollection and List=Lists/FavoriteSites attributes specified for field {c80e8e3c-7124-4772-a39d-5b69f131d542} in feature {d86c7005-d31d-43ae-b86b-38f28b81072e} could not be found. Set List={39CEC23E-FB28-47B3-BC36-C21780AD1D94}.
I don't understand it because list FavoriteSites exists. FavoriteSites list and also second list with Site field are deployed by one feature on site collection scope.
I can't specify list in lookup by GUID because I don't know the guid in deployment time.
What that log message means is that Lists/FavoriteSites does not exist in either the site collection root site or the site where the feature is being activated (if the latter is a subsite).
If Lists/FavoriteSites is being created by a feature, then make sure that it is activated before your Fields feature. Put the ListInstance element right above your Field element if you have to. But the message is clear: the list does not exist at the time that your custom field is being provisioned to the site collection. And that is why it is not working.
To be clear, the list has to exist at the time that the feature is activated, not just when you create a list instance that will use that field.
P.S. I found this by checking the "documentation" for the Microsoft.SharePoint.SPFieldElement.PerformFixUpIfLookUpField method.
Try changing the list field to the ID of the list e.g. List="{4641f5f2-b358-4805-9d7d-e910d2243fb5}"
I would also recommend using SharePointManager to look at the Field definition of your manually created field and to easily find the blooming guids of lists etc.
I had the same problem. In the end my problem was that you can not declaratively reference a list that is in the rootweb. The ~sitecollection token in the WebId property is not working because it will write the Guid between braces, while SharePoint expects it without braces (explanation can be found on http://martensboarterstun.wordpress.com/2013/06/15/how-to-create-a-list-definition-with-a-lookup-field-declaratively/). I ended up placing the Rootweb ID in my list definition.
When beginning to develop against SharePoint I did not fully understand all the ins and outs initially. I created a list definition (for a document library) and associated various custom actions to it. Unfortunately, I used the following for the list definition itself:
<ListTemplate...
...
Type="101"
...
And to register the CustomActions against the list:
<CustomAction...
...
RegistrationType="List"
RegistrationId="101"
...
Of course, this means that the custom actions are visible for all document libraries where the feature is activated which is undesirable behaviour. Also, there are lots of these document libraries that have been created from the above list definition in production.
What is the best way to fix this problem? My assumption is that I somehow need to change the "Type" attribute of the already existing lists, but I do not know how to do that. Can it be done via some direct SQL manipulation perhaps? Or is there a better way?
Note: I can see that the AllLists table has a column tp_ServerTemplate, is that the right thing to change?
Modifying the SharePoint database is completely unsupported by Microsoft. Please do not do this on production!
Another option is to create a content type and associate the custom action with that. You may need to write a simple console application to iterate through your existing document libraries and add the content type so it is available for use. The existing documents that you'd like the custom action to apply to would need their content types changed as well.
From some quick initial testing it does look like changing the AllLists table does the trick.
So steps to resolve:
1) Change List Definition Type attribute to be a unique value (for example 11000)
2) Change the CustomAction RegistrationId attributes to be the same (11000)
3) Update the tp_servertemplate column in the AllLists table to be the new template Type (11000) for all the relevant lists.