Sp-dev-docs: Idempotent issue in Site Scripts with createSPList

[sympmarc]

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?