Idempotent issue in Site Scripts with createSPList

[sympmarc]

trafficstars

Category

• [ ] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Expected or Desired Behavior

When I create a new list/library in a Site Script and rename it, I should be able to rerun the Site Script at any time and not end up with duplicate lists. The reason I rename it is to start with a clean URL ("FunctionalAreaDocuments") but have a pretty Title ("Functional Area Documents").

Observed Behavior

When I run this snippet in a Site Script a second time, I end up with a second "Functional Area Documents" library. the two libraries have the same Title, but the URLs are:

• [sitePath]/FunctionalAreaDocuments
• [sitePath]/FunctionalAreaDocuments1

        {
            "verb": "createSPList",
            "listName": "FunctionalAreaDocuments",
            "templateType": 101,
            "subactions": [
                {
                    "verb": "setTitle",
                    "title": "Functional Area Documents"
                }
            ]
        },

Steps to Reproduce

Run the Site Script snippet above twice - or more. (More times would yield more duplicates.)

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[andrewconnell]

Tagging as a question... not sure this is a bug as the behavior mirrors other parts of the SP list/column/etc creation experience so it might be "by design"...

[sympmarc]

Unfortunately, if it's "by design", there's no workaround other than using the "ugly" URL. As far as I can tell, there isn't an idempotent option here. @BobGerman

[andrewconnell]

Or... create the list, then use the REST API to change the name. Same process we do today... I'm not heavily experienced in site design scripts so not sure what is / isn't "by spec"

[sympmarc]

There are a bunch of idempotency issue with Site Scripts that aren't addressed in the docs - and it's difficult to figure out the right answer, even using the schema. I want to get these logged so we can improve the docs and usage, per discussions with @seansquires and others.

[bcameron1231]

Agreed with @sympmarc on improving docs and usage. I think we are lacking a bit of clarity on the intentions of actions in Site Scripts in regards to being idempotent. Some actions behave differently in this regard, and it's unclear whether it's intended functionality or a bug. If there was a clear understanding that doing 'x' will cause 'y', we at least up front know whether the site script will actually suit our needs.

I've ran into this scenario as well, and I personally feel the duplicate list shouldn't happen. It would just be nice to know if the duplicate is in fact, intended functionality. Feels like a bug to me. I think the site script should use an internal value for referencing a list, not the name of the list... and also extending the site script action to allow for a URL property would be convenient for control.

[sympmarc]

Any idea when this "fixed-next-drop" is happening?

[bcameron1231]

Looking at the PR, it seems this is just "intended behavior".

[sympmarc]

Yeah, I didn't see anything that specifically answered the question or explained how it ought to work. I thought I must be missing something.

The changed line is:

Once createSPList is applied on a site, runnning [sic] the createSPList with the same list name will act as an update to the existing list.

Per above, this is not the case.

[andrewconnell]

@sympmarc "fixed-next-drop" only applies to the docs... it's not a code / service update. When will that be? Dunno... whenever the latest docs update is pushed from master > live

Maybe I misunderstood the point... I thought the changes to the doc reflected what you were saying. Is that not the case?

[sympmarc]

@andrewconnell - Sorry for the delayed reply. No, it's not a doc change thing, unless it's to say that the bug above isn't a bug and the doc change explains it. To me, it doesn't. The list name change means I end up with more than one list. The "list name" shouldn't be the idempotent "key". IMO, there should be a Url parameter - or something which stays unique even after running with additional verbs.

[prasantabhowmik]

@bcameron1231 Thanks for the closing the duplicate case. But cant see any update about the alternate way or workaround, will it be fixed anytime soon.

Thanks, Pras

[piteerus]

Guys, any update in regards? I stumbled upon this issue today and I irritated by the default behavior of having duplicated lists. The "listName" property seems useless when you would like to have more user-friendly list names :/

[bcameron1231]

@piteerus Unfortunately this was marked as intended functionality. Site Scripts use the list name as the key for the list.

My suggestion would be to add a new item as an enhancement instead of a bug if one doesn't already exist.

[andrewconnell]

@bcameron1231 In that case, shouldn't we close this issue?

[jensotto]

If the key is the list title wouldn't it be best to remove the option to set a new list title, and instead provide an option to specify a different URL? Now both title and URL will be set to the value specified for listName. It does not make much sense til allow changing the key (setTitle) of a list when creating it. Alternatively the URL could be the key.

[jensotto]

When thinking a bit more on this and testing it out, I don't see how the title can be considered a key. It's perfectly legal to have multiple lists with the same title. Because of this the title can't and should not be the key. Could the implementation of this be changed somehow?

[bcameron1231]

@jensotto Agreed. This is something I've been asking for, for a long time. Hoping we can get an update to Site Scripts to allow for this...

[sympmarc]

@bcameron1231 - A guy can dream...

[jensotto]

Almost a year has passed with no progress on this. Are there any indications that this will be looked into? I must say that for me Site Scripts are a bit useless for creating lists because of this issue. Lists will get the annoying %20 in the URL if the list title contains a space. This is also true for several other characters used in the site title. It makes it impossible to design nice looking and readable URLs.

[virtualducttape]

Agreed, this is completely incorrect behavior... the Title can't be a key because we can have multiple lists with identical Titles. There is currently no way to use site scripts in a "repeatable application" manner... even if we use the Rest API as suggested to change the name, the next time we apply the site template, it will still look for a list with a matching title, fail to find one, and create a new list.

[sympmarc]

This is biting me again today. So frustrating.

The way setTitle was implemented as a subaction of createSPList means it makes it worse, too.

{
  "verb": "setTitle",
  "title": "Customers and Orders"
}