Pnp-sites-core: Renaming Title field in list not working wiht PnP

Created on 22 Jul 2016  Â·  15Comments  Â·  Source: pnp/PnP-Sites-Core

Which PnP repository to report the issue?

[X ] Bug
[ ] Enhancement

Environment

[ X] Office 365 / SharePoint Online
[] SharePoint 2016
[] SharePoint 2013

Expected or Desired Behavior

When a Title field is renamed in a list this should be included in the exported xml.

Observed Behavior

Steps:

  1. export a site using PowerShell resulting in an xml
  2. create a custom list
  3. rename the title field in the list settings
  4. export the site again
  5. compare the two files

The difference now is:

< pnp:ListInstance Title="TestList" Description="" DocumentTemplate="" TemplateType="100" Url="Lists/TestList" MinorVersionLimit="0" MaxVersionLimit="0" DraftVersionVisibility="0" TemplateFeatureID="00bfea71-de22-43b2-a848-c05709900100" EnableFolderCreation="false">
< pnp:ContentTypeBindings>
< pnp:ContentTypeBinding ContentTypeID="0x01" Default="true" />
< pnp:ContentTypeBinding ContentTypeID="0x0120" />
< /pnp:ContentTypeBindings>
< pnp:Views>
< View Name="{BD0B9A70-6F36-480D-90B1-846CAA53B8B8}" DefaultView="TRUE" MobileView="TRUE" MobileDefaultView="TRUE" Type="HTML" DisplayName="All Items" Url="/Lists/TestList/AllItems.aspx" Level="1" BaseViewID="1" ContentTypeID="0x" ImageUrl="/_layouts/15/images/generic.png?rev=43">
< Query>
< OrderBy>
< FieldRef Name="ID" />
< /OrderBy>
< /Query>
< ViewFields>
< FieldRef Name="LinkTitle" />
< /ViewFields>
< RowLimit Paged="TRUE">30
< JSLink>clienttemplates.js
< /View>
< /pnp:Views>
< /pnp:ListInstance>

This problem is only an export issue. if you add the following in the lists instance then it works:

pnp:FieldRefs
<pnp:FieldRef .....

Steps to Reproduce

See above

Most helpful comment

I'm in no rush at the moment, but if I need it before @Pieter-Veenstra does I'll propose something. That said, I agree that leaving it alone is good form - perhaps making it non-mandatory and hiding it. And appreciate you taking one more round on this :)

Unfortunately we cannot always control our user base.

All 15 comments

internal testing feedback
Exported template. Created custom list. Rename the title field in the list settings. Exported template.
No difference observed when compared the two files, so issue is reproducible.

Adding enhancement label

Any news about this issue/enhancement guys?

Best Regards!

Hi,
Thanks for your feedback. We discussed internally this issue and, as a best practice, we do not encourage renaming the Title field of a list. Thus, we will not merge any related PR/fix. I will close this item.

Hi Paolo, I totally agree, however where SharePoint up to 2013 made it impossible to rename a title field since that version the SharePoint interface allows you to rename the title field. Not best practise maybe but fully supported by the SharePoint team.

Hi Pieter,
You're right, but I still remember a mantra from the MCM certification training: "Just because you can, doesn't mean you should" :-) ...

Hmm. Not 100% sure why pnp templates should block functionality which is in
pnp core. You could support it, but write a warning.

We can localize list titles right? Which is really no different in a
functional perspective? (playing devils advocate, not being an mcm ;)

-mikael

ons. 27. des. 2017 kl. 13:17 skrev Paolo Pialorsi <[email protected]

:

Hi Pieter,
You're right, but I still remember a mantra from the MCM certification
training: "Just because you can, doesn't mean you should" :-) ...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/SharePoint/PnP-Sites-Core/issues/676#issuecomment-354105812,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADHoLX5c_zjPv0HZvH-S_qKtKvvtFTkks5tEjVlgaJpZM4JS0FE
.

I agree with @wobba my users are definitely nowhere near the level of an MCM and the site they create can't be recreated with PnP. So a warning would be great, support even better

Hi @wobba and @Pieter-Veenstra,
Yes, we support localization for lists' title and for some other text-properties through tokenization, but we don't have any out of the box resource file with pre-translated values in all of the available languages. That's because it simply wouldn't scale to have all texts in all languages, and at the same time, it would be not consistent to have such capability just for Name and Display Name of some of the fields. That's why we decided to close the PR #1376.

On the other hand, considering that PnP stands for Patterns and Practices, we need to help the community to adhere to best practices, avoiding worse ones.

Having a warning or a flag argument to force the "wrong" behavior could be a "politically correct" solution, but we need to keep into account that any PR merged into PnP-Sites-Core has to be maintainable and scalable. Thus feel free to submit a PR with a different approach, if compared with #1376, and maybe we will merge it, after proper evaluation.

I hope you are not getting me wrong, and you understand the point of view.

Thanks,
Paolo

I'm all good and a good point remembering what pnp stands for :)

Could you elaborate on the technical issues this functionality can/will
cause in order for us to learn? Renaming a Title field is quite a common
thing to do as the default behavior is required.

Keep up the scrutinizing :)

ons. 27. des. 2017 kl. 15:35 skrev Paolo Pialorsi <[email protected]

:

Hi @wobba https://github.com/wobba and @Pieter-Veenstra
https://github.com/pieter-veenstra,
Yes, we support localization for lists' title and for some other
text-properties through tokenization, but we don't have any out of the box
resource file with pre-translated values in all of the available languages.
That's because it simply wouldn't scale to have all texts in all languages,
and at the same time, it would be not consistent to have such capability
just for Name and Display Name of some of the fields. That's why we decided
to close the PR #1376
https://github.com/SharePoint/PnP-Sites-Core/pull/1376.

On the other hand, considering that PnP stands for Patterns and Practices,
we need to help the community to adhere to best practices, avoiding worse
ones.

Having a warning or a flag argument to force the "wrong" behavior could be
a "politically correct" solution, but we need to keep into account that any
PR merged into PnP-Sites-Core has to be maintainable and scalable. Thus
feel free to submit a PR with a different approach, if compared with #1376
https://github.com/SharePoint/PnP-Sites-Core/pull/1376, and maybe we
will merge it, after proper evaluation.

I hope you are not getting me wrong, and you understand the point of view.

Thanks,
Paolo

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SharePoint/PnP-Sites-Core/issues/676#issuecomment-354122527,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADHoMlA3eK3scV7LiX5GAeCtyROPnkrks5tElXOgaJpZM4JS0FE
.

Hi @wobba,
About your question: just to make an example, renaming the Title field is not a good habit because that one is a kind of "fixed" field. Think for example about the Server Object Model, where the Title member has a fixed name. Client-side, in CSOM, we don't have the same fixed member in the ListItem object, but still renaming the Title can be compromising for other references.

About the need to be able to export/import templates with renamed Title fields: we decided, after further internal discussion, to implement that capability (accordingly to our spare time availability) and to raise a warning whenever we find a Title field renamed. Feel free to make a proposal, if you are in a rush, as long as the proposal will not be too much complex from a code maintenance perspective. Thanks.

I hope this will help.
Take care,
Paolo

I'm in no rush at the moment, but if I need it before @Pieter-Veenstra does I'll propose something. That said, I agree that leaving it alone is good form - perhaps making it non-mandatory and hiding it. And appreciate you taking one more round on this :)

Unfortunately we cannot always control our user base.

I would agree with the "making it non-mandatory and hiding it" as suggested by @wobba

Just want to add.. the issue with Title and hiding it, is that in modern view you loose the ellipses ... edit menu per item, as the Edit column does not show. Which is why people rename Title to, "Name", "Item" or what not to suit the content of a list.

Also a PowerApp view form will now show without the Title column.

Hi,
SharePoint Interface allows any user to change the display name of the Title column. Is it an anti pattern to adapt a default column display name to users need ?
I would love to fully automate my list creation with PowerShell PnP.

@jmthia From a technical viewpoint it might be, but from a user point of view it makes sense, as so much UI capability is tied to the Title field. For a doclib I would leave it, for most lists the ellipses/context menu might not be needed, so hiding it might work just fine.

Was this page helpful?
0 / 5 - 0 ratings