Re: Content Types and SharePoint 2010

2011-04-17 Thread Alex Hobson
We have had not more luck attempting to fix up the duplicate fields using
the Object Model since it appears they are referencing the same site column.

The fields do appear to be linked. If you update one it does appears to
effect the other.

On Mon, Apr 18, 2011 at 2:02 PM, Brian Farnhill wrote:

> You could just accept that doing things declaratively through CAML is just
> horrible and write some code to fix your columns up in the feature receiver
> J
>
>
>
> *[image: Description: Description: avatarpic-l]***
>
> *Brian Farnhill*
> *Solutions Architect, Extelligent Design | SharePoint Server MVP*
> phone: 0408 289 303 | twitter: 
> @BrianFarnhill| blog:
> blog.brianfarnhill.com | xbox: Noble 
> Downfall
>
>
>
>
>
> *From:* ozmoss-boun...@ozmoss.com [mailto:ozmoss-boun...@ozmoss.com] *On
> Behalf Of *Alex Hobson
> *Sent:* Monday, 18 April 2011 1:59 PM
> *To:* ozMOSS
> *Subject:* Re: Content Types and SharePoint 2010
>
>
>
> Yeah saw that element. In my Common CT i have added the RemoveFieldRef
> element to remove the Title field but to no effect. The Title field will
> remain. If i add the FieldRef for Title after the RemoveFieldRef i again
> have duplicate columns.
>
> On Mon, Apr 18, 2011 at 1:24 PM, Sezai Komur 
> wrote:
>
>  ?
>
> http://msdn.microsoft.com/en-us/library/aa543602.aspx
>
>
> http://sharepointlive.blogspot.com/2009/05/content-types-inheritance-how-to-remove.html
>
> http://www.u2u.info/Blogs/karine/Lists/Posts/Post.aspx?ID=6
>
>
>
> No idea if this will actually work though, worth a shot.
>
>
>
> Sezai.
>
> On Mon, Apr 18, 2011 at 10:50 AM, Alex Hobson  wrote:
>
> In MOSS 2007 the SystemPage CT did not have the attribute Inherits="TRUE"
> so when our Common CT inherited from SystemPage and we changed the
> DisplayName we did not have an issue.
>
> If you have a look the Document (0x0101) and Item (0x01) CTs you will see
> what i mean.
>
> The Item CT has the Title FieldRef and has Required="TRUE" the Document CT
> references the Title FieldRef and has Required="FALSE".
>
> So in the Document CT Title is not required. Where in the Item CT Title is
> required.
>
> Once you get up to the SystemPage CT we see the Inherits="TRUE" attribute.
> This appears to change the game, if i try and add the Title FieldRef into my
> Common CT and updated the DisplayName i get an duplicate field instead of
> overriding the field like i use to have.
>
> BTW this is not unique to Title, it is just an example.
>
> On Mon, Apr 18, 2011 at 11:37 AM, Prashanth Thiyagalingam <
> prashanth...@hotmail.com> wrote:
>
> SystemPage CT has already got the build-in Title field inherited
> from 'Item' CT, and this is what is causing the duplicate error.
>
> --
>
> Date: Mon, 18 Apr 2011 10:29:26 +1000
> Subject: Content Types and SharePoint 2010
> From: a...@hobsonator.com
> To: ozmoss@ozmoss.com
>
>
>
>
>
> We have run into an interesting issue when migrating our WSP packages from
> MOSS 2007 to SharePoint 2010. The issue is in relation to Publishing Content
> Types.
>
> In the past we have had a Common Publishing Content Type called
> CommonPublishingContentTypes which inherits from the built-in SystemPage
> Content Type (0x010100C568DB52D9D0A14D9B2FDCC9E9F2) found in the
> PublishingResources Feature.
>
>
>
> SharePoint 2010 appears to have introduced a attribute called Inherits and
> on the built-in SystemPage Content Type this is set to TRUE. "If Inherits is
> TRUE, the child content type inherits all fields that are in the parent,
> including fields that users have added." (
> http://msdn.microsoft.com/en-us/library/aa544268.aspx).
>
>
>
> In MOSS 2007 we where able to add a built-in field  ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" DisplayName="Title"
> Required="TRUE"/> into our CommonPublishingContentTypes and updated the
> DisplayName or Required attributes.
>
>
>
> If we attempt to do this in SharePoint 2010 we get duplicate fields in our
> CommonPublishingContentTypes Content Type for Title.
>
> Ideas?
>
>
>
> ___ ozmoss mailing list
> ozmoss@ozmoss.com http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
>
>
>
> ___
>
>
> ozmoss mailing list
> ozmoss@ozmoss.com
> http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
>
>
>
> ___
>
>
> ozmoss mailing list
> ozmoss@ozmoss.com
> http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
>
>
>
>
> ___
> ozmoss mailing list
> ozmoss@ozmoss.com
> http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
>
>
>
> ___
> ozmoss mailing list
> ozmoss@ozmoss.com
> http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
>
>
___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm

RE: Content Types and SharePoint 2010

2011-04-17 Thread Aaron Saikovski
Have a chat to Elaine Van Bergen about this.
She has some very vocal and strong opinions on this topic and isn't afraid to 
share them ;-)



Regards,

Aaron Saikovski | Senior Consultant | Microsoft Services Australia
[Description: cid:image001.png@01CBCE95.82E00700]
' +61 2 8817 9280 |È +61 410 480 971 | 7 +61 2 9870 2499 | Blog: 
http://blogs.msdn.com/aaronsaikovski  | 
Web: 
www.microsoft.com/australia/services

From: ozmoss-boun...@ozmoss.com [mailto:ozmoss-boun...@ozmoss.com] On Behalf Of 
Brian Farnhill
Sent: Monday, 18 April 2011 12:02 PM
To: ozMOSS
Subject: RE: Content Types and SharePoint 2010

You could just accept that doing things declaratively through CAML is just 
horrible and write some code to fix your columns up in the feature receiver :)

[Description: Description: avatarpic-l]

Brian Farnhill
Solutions Architect, Extelligent Design | SharePoint Server MVP
phone: 0408 289 303 | twitter: @BrianFarnhill 
| blog: blog.brianfarnhill.com | xbox: Noble 
Downfall



From: ozmoss-boun...@ozmoss.com [mailto:ozmoss-boun...@ozmoss.com] On Behalf Of 
Alex Hobson
Sent: Monday, 18 April 2011 1:59 PM
To: ozMOSS
Subject: Re: Content Types and SharePoint 2010

Yeah saw that element. In my Common CT i have added the RemoveFieldRef element 
to remove the Title field but to no effect. The Title field will remain. If i 
add the FieldRef for Title after the RemoveFieldRef i again have duplicate 
columns.
On Mon, Apr 18, 2011 at 1:24 PM, Sezai Komur 
mailto:sharepointse...@gmail.com>> wrote:
 ?
http://msdn.microsoft.com/en-us/library/aa543602.aspx
http://sharepointlive.blogspot.com/2009/05/content-types-inheritance-how-to-remove.html
http://www.u2u.info/Blogs/karine/Lists/Posts/Post.aspx?ID=6

No idea if this will actually work though, worth a shot.

Sezai.
On Mon, Apr 18, 2011 at 10:50 AM, Alex Hobson 
mailto:a...@hobsonator.com>> wrote:
In MOSS 2007 the SystemPage CT did not have the attribute Inherits="TRUE" so 
when our Common CT inherited from SystemPage and we changed the DisplayName we 
did not have an issue.

If you have a look the Document (0x0101) and Item (0x01) CTs you will see what 
i mean.

The Item CT has the Title FieldRef and has Required="TRUE" the Document CT 
references the Title FieldRef and has Required="FALSE".

So in the Document CT Title is not required. Where in the Item CT Title is 
required.

Once you get up to the SystemPage CT we see the Inherits="TRUE" attribute. This 
appears to change the game, if i try and add the Title FieldRef into my Common 
CT and updated the DisplayName i get an duplicate field instead of overriding 
the field like i use to have.

BTW this is not unique to Title, it is just an example.
On Mon, Apr 18, 2011 at 11:37 AM, Prashanth Thiyagalingam 
mailto:prashanth...@hotmail.com>> wrote:
SystemPage CT has already got the build-in Title field inherited from 'Item' 
CT, and this is what is causing the duplicate error.


Date: Mon, 18 Apr 2011 10:29:26 +1000
Subject: Content Types and SharePoint 2010
From: a...@hobsonator.com
To: ozmoss@ozmoss.com


We have run into an interesting issue when migrating our WSP packages from MOSS 
2007 to SharePoint 2010. The issue is in relation to Publishing Content Types.
In the past we have had a Common Publishing Content Type called 
CommonPublishingContentTypes which inherits from the built-in SystemPage 
Content Type (0x010100C568DB52D9D0A14D9B2FDCC9E9F2) found in the 
PublishingResources Feature.

SharePoint 2010 appears to have introduced a attribute called Inherits and on 
the built-in SystemPage Content Type this is set to TRUE. "If Inherits is TRUE, 
the child content type inherits all fields that are in the parent, including 
fields that users have added." 
(http://msdn.microsoft.com/en-us/library/aa544268.aspx).

In MOSS 2007 we where able to add a built-in field  into our CommonPublishingContentTypes and updated the 
DisplayName or Required attributes.

If we attempt to do this in SharePoint 2010 we get duplicate fields in our 
CommonPublishingContentTypes Content Type for Title.

Ideas?

___ ozmoss mailing list 
ozmoss@ozmoss.com 
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss

___

ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss

___

ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss


___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.c

RE: Content Types and SharePoint 2010

2011-04-17 Thread Brian Farnhill
You could just accept that doing things declaratively through CAML is just 
horrible and write some code to fix your columns up in the feature receiver :)

[cid:image001.png@01CBFDD1.357826D0]

Brian Farnhill
Solutions Architect, Extelligent Design | SharePoint Server MVP
phone: 0408 289 303 | twitter: @BrianFarnhill 
| blog: blog.brianfarnhill.com | xbox: Noble 
Downfall



From: ozmoss-boun...@ozmoss.com [mailto:ozmoss-boun...@ozmoss.com] On Behalf Of 
Alex Hobson
Sent: Monday, 18 April 2011 1:59 PM
To: ozMOSS
Subject: Re: Content Types and SharePoint 2010

Yeah saw that element. In my Common CT i have added the RemoveFieldRef element 
to remove the Title field but to no effect. The Title field will remain. If i 
add the FieldRef for Title after the RemoveFieldRef i again have duplicate 
columns.
On Mon, Apr 18, 2011 at 1:24 PM, Sezai Komur 
mailto:sharepointse...@gmail.com>> wrote:
 ?
http://msdn.microsoft.com/en-us/library/aa543602.aspx
http://sharepointlive.blogspot.com/2009/05/content-types-inheritance-how-to-remove.html
http://www.u2u.info/Blogs/karine/Lists/Posts/Post.aspx?ID=6

No idea if this will actually work though, worth a shot.

Sezai.
On Mon, Apr 18, 2011 at 10:50 AM, Alex Hobson 
mailto:a...@hobsonator.com>> wrote:
In MOSS 2007 the SystemPage CT did not have the attribute Inherits="TRUE" so 
when our Common CT inherited from SystemPage and we changed the DisplayName we 
did not have an issue.

If you have a look the Document (0x0101) and Item (0x01) CTs you will see what 
i mean.

The Item CT has the Title FieldRef and has Required="TRUE" the Document CT 
references the Title FieldRef and has Required="FALSE".

So in the Document CT Title is not required. Where in the Item CT Title is 
required.

Once you get up to the SystemPage CT we see the Inherits="TRUE" attribute. This 
appears to change the game, if i try and add the Title FieldRef into my Common 
CT and updated the DisplayName i get an duplicate field instead of overriding 
the field like i use to have.

BTW this is not unique to Title, it is just an example.
On Mon, Apr 18, 2011 at 11:37 AM, Prashanth Thiyagalingam 
mailto:prashanth...@hotmail.com>> wrote:
SystemPage CT has already got the build-in Title field inherited from 'Item' 
CT, and this is what is causing the duplicate error.


Date: Mon, 18 Apr 2011 10:29:26 +1000
Subject: Content Types and SharePoint 2010
From: a...@hobsonator.com
To: ozmoss@ozmoss.com


We have run into an interesting issue when migrating our WSP packages from MOSS 
2007 to SharePoint 2010. The issue is in relation to Publishing Content Types.
In the past we have had a Common Publishing Content Type called 
CommonPublishingContentTypes which inherits from the built-in SystemPage 
Content Type (0x010100C568DB52D9D0A14D9B2FDCC9E9F2) found in the 
PublishingResources Feature.

SharePoint 2010 appears to have introduced a attribute called Inherits and on 
the built-in SystemPage Content Type this is set to TRUE. "If Inherits is TRUE, 
the child content type inherits all fields that are in the parent, including 
fields that users have added." 
(http://msdn.microsoft.com/en-us/library/aa544268.aspx).

In MOSS 2007 we where able to add a built-in field  into our CommonPublishingContentTypes and updated the 
DisplayName or Required attributes.

If we attempt to do this in SharePoint 2010 we get duplicate fields in our 
CommonPublishingContentTypes Content Type for Title.

Ideas?

___ ozmoss mailing list 
ozmoss@ozmoss.com 
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss

___

ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss

___

ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss


___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss

<>___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss


Re: Content Types and SharePoint 2010

2011-04-17 Thread Alex Hobson
Yeah saw that element. In my Common CT i have added the RemoveFieldRef
element to remove the Title field but to no effect. The Title field will
remain. If i add the FieldRef for Title after the RemoveFieldRef i again
have duplicate columns.

On Mon, Apr 18, 2011 at 1:24 PM, Sezai Komur wrote:

>  ?
> http://msdn.microsoft.com/en-us/library/aa543602.aspx
>
> http://sharepointlive.blogspot.com/2009/05/content-types-inheritance-how-to-remove.html
> http://www.u2u.info/Blogs/karine/Lists/Posts/Post.aspx?ID=6
>
>
> No
> idea if this will actually work though, worth a shot.
>
> Sezai.
>
> On Mon, Apr 18, 2011 at 10:50 AM, Alex Hobson  wrote:
>
>> In MOSS 2007 the SystemPage CT did not have the attribute Inherits="TRUE"
>> so when our Common CT inherited from SystemPage and we changed the
>> DisplayName we did not have an issue.
>>
>> If you have a look the Document (0x0101) and Item (0x01) CTs you will see
>> what i mean.
>>
>> The Item CT has the Title FieldRef and has Required="TRUE" the Document CT
>> references the Title FieldRef and has Required="FALSE".
>>
>> So in the Document CT Title is not required. Where in the Item CT Title is
>> required.
>>
>> Once you get up to the SystemPage CT we see the Inherits="TRUE" attribute.
>> This appears to change the game, if i try and add the Title FieldRef into my
>> Common CT and updated the DisplayName i get an duplicate field instead of
>> overriding the field like i use to have.
>>
>> BTW this is not unique to Title, it is just an example.
>>
>> On Mon, Apr 18, 2011 at 11:37 AM, Prashanth Thiyagalingam <
>> prashanth...@hotmail.com> wrote:
>>
>>>  SystemPage CT has already got the build-in Title field inherited
>>> from 'Item' CT, and this is what is causing the duplicate error.
>>>
>>> --
>>> Date: Mon, 18 Apr 2011 10:29:26 +1000
>>> Subject: Content Types and SharePoint 2010
>>> From: a...@hobsonator.com
>>> To: ozmoss@ozmoss.com
>>>
>>>
>>>
>>> We have run into an interesting issue when migrating our WSP packages
>>> from MOSS 2007 to SharePoint 2010. The issue is in relation to Publishing
>>> Content Types.
>>>
>>> In the past we have had a Common Publishing Content Type called
>>> CommonPublishingContentTypes which inherits from the built-in SystemPage
>>> Content Type (0x010100C568DB52D9D0A14D9B2FDCC9E9F2) found in the
>>> PublishingResources Feature.
>>>
>>> SharePoint 2010 appears to have introduced a attribute called Inherits
>>> and on the built-in SystemPage Content Type this is set to TRUE. "If
>>> Inherits is TRUE, the child content type inherits all fields that are in the
>>> parent, including fields that users have added." (
>>> http://msdn.microsoft.com/en-us/library/aa544268.aspx).
>>>
>>> In MOSS 2007 we where able to add a built-in field >> ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" DisplayName="Title"
>>> Required="TRUE"/> into our CommonPublishingContentTypes and updated the
>>> DisplayName or Required attributes.
>>>
>>> If we attempt to do this in SharePoint 2010 we get duplicate fields in
>>> our CommonPublishingContentTypes Content Type for Title.
>>>
>>> Ideas?
>>>
>>> ___ ozmoss mailing list
>>> ozmoss@ozmoss.com http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
>>>
>>> ___
>>>
>>> ozmoss mailing list
>>> ozmoss@ozmoss.com
>>> http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
>>>
>>>
>>
>> ___
>>
>> ozmoss mailing list
>> ozmoss@ozmoss.com
>> http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
>>
>>
>
> ___
> ozmoss mailing list
> ozmoss@ozmoss.com
> http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
>
>
___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss


Re: Content Types and SharePoint 2010

2011-04-17 Thread Sezai Komur
 ?
http://msdn.microsoft.com/en-us/library/aa543602.aspx
http://sharepointlive.blogspot.com/2009/05/content-types-inheritance-how-to-remove.html
http://www.u2u.info/Blogs/karine/Lists/Posts/Post.aspx?ID=6

No
idea if this will actually work though, worth a shot.

Sezai.

On Mon, Apr 18, 2011 at 10:50 AM, Alex Hobson  wrote:

> In MOSS 2007 the SystemPage CT did not have the attribute Inherits="TRUE"
> so when our Common CT inherited from SystemPage and we changed the
> DisplayName we did not have an issue.
>
> If you have a look the Document (0x0101) and Item (0x01) CTs you will see
> what i mean.
>
> The Item CT has the Title FieldRef and has Required="TRUE" the Document CT
> references the Title FieldRef and has Required="FALSE".
>
> So in the Document CT Title is not required. Where in the Item CT Title is
> required.
>
> Once you get up to the SystemPage CT we see the Inherits="TRUE" attribute.
> This appears to change the game, if i try and add the Title FieldRef into my
> Common CT and updated the DisplayName i get an duplicate field instead of
> overriding the field like i use to have.
>
> BTW this is not unique to Title, it is just an example.
>
> On Mon, Apr 18, 2011 at 11:37 AM, Prashanth Thiyagalingam <
> prashanth...@hotmail.com> wrote:
>
>>  SystemPage CT has already got the build-in Title field inherited
>> from 'Item' CT, and this is what is causing the duplicate error.
>>
>> --
>> Date: Mon, 18 Apr 2011 10:29:26 +1000
>> Subject: Content Types and SharePoint 2010
>> From: a...@hobsonator.com
>> To: ozmoss@ozmoss.com
>>
>>
>>
>> We have run into an interesting issue when migrating our WSP packages from
>> MOSS 2007 to SharePoint 2010. The issue is in relation to Publishing Content
>> Types.
>>
>> In the past we have had a Common Publishing Content Type called
>> CommonPublishingContentTypes which inherits from the built-in SystemPage
>> Content Type (0x010100C568DB52D9D0A14D9B2FDCC9E9F2) found in the
>> PublishingResources Feature.
>>
>> SharePoint 2010 appears to have introduced a attribute called Inherits and
>> on the built-in SystemPage Content Type this is set to TRUE. "If Inherits is
>> TRUE, the child content type inherits all fields that are in the parent,
>> including fields that users have added." (
>> http://msdn.microsoft.com/en-us/library/aa544268.aspx).
>>
>> In MOSS 2007 we where able to add a built-in field > ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" DisplayName="Title"
>> Required="TRUE"/> into our CommonPublishingContentTypes and updated the
>> DisplayName or Required attributes.
>>
>> If we attempt to do this in SharePoint 2010 we get duplicate fields in our
>> CommonPublishingContentTypes Content Type for Title.
>>
>> Ideas?
>>
>> ___ ozmoss mailing list
>> ozmoss@ozmoss.com http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
>>
>> ___
>>
>> ozmoss mailing list
>> ozmoss@ozmoss.com
>> http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
>>
>>
>
> ___
> ozmoss mailing list
> ozmoss@ozmoss.com
> http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
>
>
___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss


Re: Content Types and SharePoint 2010

2011-04-17 Thread Alex Hobson
In MOSS 2007 the SystemPage CT did not have the attribute Inherits="TRUE" so
when our Common CT inherited from SystemPage and we changed the DisplayName
we did not have an issue.

If you have a look the Document (0x0101) and Item (0x01) CTs you will see
what i mean.

The Item CT has the Title FieldRef and has Required="TRUE" the Document CT
references the Title FieldRef and has Required="FALSE".

So in the Document CT Title is not required. Where in the Item CT Title is
required.

Once you get up to the SystemPage CT we see the Inherits="TRUE" attribute.
This appears to change the game, if i try and add the Title FieldRef into my
Common CT and updated the DisplayName i get an duplicate field instead of
overriding the field like i use to have.

BTW this is not unique to Title, it is just an example.

On Mon, Apr 18, 2011 at 11:37 AM, Prashanth Thiyagalingam <
prashanth...@hotmail.com> wrote:

>  SystemPage CT has already got the build-in Title field inherited
> from 'Item' CT, and this is what is causing the duplicate error.
>
> --
> Date: Mon, 18 Apr 2011 10:29:26 +1000
> Subject: Content Types and SharePoint 2010
> From: a...@hobsonator.com
> To: ozmoss@ozmoss.com
>
>
>
> We have run into an interesting issue when migrating our WSP packages from
> MOSS 2007 to SharePoint 2010. The issue is in relation to Publishing Content
> Types.
>
> In the past we have had a Common Publishing Content Type called
> CommonPublishingContentTypes which inherits from the built-in SystemPage
> Content Type (0x010100C568DB52D9D0A14D9B2FDCC9E9F2) found in the
> PublishingResources Feature.
>
> SharePoint 2010 appears to have introduced a attribute called Inherits and
> on the built-in SystemPage Content Type this is set to TRUE. "If Inherits is
> TRUE, the child content type inherits all fields that are in the parent,
> including fields that users have added." (
> http://msdn.microsoft.com/en-us/library/aa544268.aspx).
>
> In MOSS 2007 we where able to add a built-in field  ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" DisplayName="Title"
> Required="TRUE"/> into our CommonPublishingContentTypes and updated the
> DisplayName or Required attributes.
>
> If we attempt to do this in SharePoint 2010 we get duplicate fields in our
> CommonPublishingContentTypes Content Type for Title.
>
> Ideas?
>
> ___ ozmoss mailing list
> ozmoss@ozmoss.com http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
>
> ___
> ozmoss mailing list
> ozmoss@ozmoss.com
> http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
>
>
___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss


RE: Content Types and SharePoint 2010

2011-04-17 Thread Prashanth Thiyagalingam

SystemPage CT has already got the build-in Title field inherited from 'Item' 
CT, and this is what is causing the duplicate error.
 


Date: Mon, 18 Apr 2011 10:29:26 +1000
Subject: Content Types and SharePoint 2010
From: a...@hobsonator.com
To: ozmoss@ozmoss.com



We have run into an interesting issue when migrating our WSP packages from MOSS 
2007 to SharePoint 2010. The issue is in relation to Publishing Content Types.


In the past we have had a Common Publishing Content Type called 
CommonPublishingContentTypes which inherits from the built-in SystemPage 
Content Type (0x010100C568DB52D9D0A14D9B2FDCC9E9F2) found in the 
PublishingResources Feature.
 
SharePoint 2010 appears to have introduced a attribute called Inherits and on 
the built-in SystemPage Content Type this is set to TRUE. "If Inherits is TRUE, 
the child content type inherits all fields that are in the parent, including 
fields that users have added." 
(http://msdn.microsoft.com/en-us/library/aa544268.aspx).
 
In MOSS 2007 we where able to add a built-in field  into our CommonPublishingContentTypes and updated the 
DisplayName or Required attributes.
 
If we attempt to do this in SharePoint 2010 we get duplicate fields in our 
CommonPublishingContentTypes Content Type for Title.

Ideas?

___ ozmoss mailing list 
ozmoss@ozmoss.com http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss 
  ___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss


RE: SharePoint, InfoPath, links and 256 charact limits

2011-04-17 Thread Nigel Hertz
I actually answered my own question on this after playing around a bit - 
virtual directories in IIS that redirect to specific URLs. I've created a 
virtual directory for each form, and so far it seems to work perfectly.



From: ozmoss-boun...@ozmoss.com [mailto:ozmoss-boun...@ozmoss.com] On Behalf Of 
Nigel Hertz
Sent: Monday, 18 April 2011 8:47 AM
To: ozMOSS
Subject: SharePoint, InfoPath, links and 256 charact limits

Hi guys

I'm sure most of you know that most of the MS Office product suite, including 
SharePoint, likes to limit URLs to 256 characters. A good example is 'ctrl-k' 
in an office document, past a long URL in, and have it chopped off at the 256th 
character. There are workarounds to get longer URLs pasted in (at least in 
Outlook, I haven't tried others)

My issue is that if I want to link directly into an InfoPath form, I can't. 
(Instead of going to the library and clicking 'New' - don't ask, but apparently 
the extra click is too much effort) What we've had to do is try create HTML 
pages that then redirect to the form using meta-refresh or some similar 
strategy. The problem with that is that opening from within search doesn't 
always work.

Has anyone encountered this and found some alternative workaround?

Nigel

The direct URL is something like this.
http://servername/OnlineForms/_layouts/FormServer.aspx?XsnLocation=http://servername/OnlineForms/FormServerTemplates/Training%20Request%20Form.xsn&SaveLocation=http%3A%2F%2Fservername%2FOnlineForms%2FTraining%20Request%20Form&Source=http%3A%2F%2Fservername%2FOnlineForms%2FTraining%2520Request%2520Form%2FForms%2FDefault%2520View%2Easpx&DefaultItemOpen=1



Stockland Notice: If this communication has been sent to you by mistake, please 
delete and notify us.  If it has been sent to you by mistake, legal privilege 
is not waived or lost and you are not entitled to use it in any way. Stockland 
and its subsidiaries reserve the right to monitor e-mail communication through 
its networks.

_

Stockland Notice: If this communication has been sent to you by mistake, please 
delete and notify us.  If it has been sent to you by mistake, legal privilege 
is not waived or lost and you are not entitled to use it in any way. Stockland 
and its subsidiaries reserve the right to monitor e-mail communication through 
its networks.
___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss


Content Types and SharePoint 2010

2011-04-17 Thread Alex Hobson
We have run into an interesting issue when migrating our WSP packages from
MOSS 2007 to SharePoint 2010. The issue is in relation to Publishing Content
Types.

In the past we have had a Common Publishing Content Type called
CommonPublishingContentTypes which inherits from the built-in SystemPage
Content Type (0x010100C568DB52D9D0A14D9B2FDCC9E9F2) found in the
PublishingResources Feature.

SharePoint 2010 appears to have introduced a attribute called Inherits and
on the built-in SystemPage Content Type this is set to TRUE. "If Inherits is
TRUE, the child content type inherits all fields that are in the parent,
including fields that users have added." (
http://msdn.microsoft.com/en-us/library/aa544268.aspx).

In MOSS 2007 we where able to add a built-in field  into our CommonPublishingContentTypes and updated the
DisplayName or Required attributes.

If we attempt to do this in SharePoint 2010 we get duplicate fields in our
CommonPublishingContentTypes Content Type for Title.

Ideas?
___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss


SharePoint, InfoPath, links and 256 charact limits

2011-04-17 Thread Nigel Hertz
Hi guys

I'm sure most of you know that most of the MS Office product suite, including 
SharePoint, likes to limit URLs to 256 characters. A good example is 'ctrl-k' 
in an office document, past a long URL in, and have it chopped off at the 256th 
character. There are workarounds to get longer URLs pasted in (at least in 
Outlook, I haven't tried others)

My issue is that if I want to link directly into an InfoPath form, I can't. 
(Instead of going to the library and clicking 'New' - don't ask, but apparently 
the extra click is too much effort) What we've had to do is try create HTML 
pages that then redirect to the form using meta-refresh or some similar 
strategy. The problem with that is that opening from within search doesn't 
always work.

Has anyone encountered this and found some alternative workaround?

Nigel

The direct URL is something like this.

http://servername/OnlineForms/_layouts/FormServer.aspx?XsnLocation=http://servername/OnlineForms/FormServerTemplates/Training%20Request%20Form.xsn&SaveLocation=http%3A%2F%2Fservername%2FOnlineForms%2FTraining%20Request%20Form&Source=http%3A%2F%2Fservername%2FOnlineForms%2FTraining%2520Request%2520Form%2FForms%2FDefault%2520View%2Easpx&DefaultItemOpen=1



_

Stockland Notice: If this communication has been sent to you by mistake, please 
delete and notify us.  If it has been sent to you by mistake, legal privilege 
is not waived or lost and you are not entitled to use it in any way. Stockland 
and its subsidiaries reserve the right to monitor e-mail communication through 
its networks.
___
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss