Calendrier de Développer Tous par défaut

Kuldeep, merci pour ce script! J'ai modifié légèrement pour développer toutes les lignes du calendrier par la suppression de la pause et de la vérification pour voir si le texte d'ancre est "l'effondrement". Si ce n'est pas "l'effondrement", un clic est exécuté. Notez que vous avez seulement besoin de cliquer sur un élément par ligne. Sinon, vous risquez de basculer à nouveau effondré.

Une autre problématique côté effet de l'ajout de la CEWP à la page du Calendrier, c'est que vous perdez la Vue Modifier liste déroulante. Vous devez utiliser le calendrier de ruban pour changer de vue.

Je tiens également à trouver une solution plus robuste, mais voici mes légèrement améliorée de la solution:

<script type="text/javascript">

_spBodyOnLoadFunctionNames.push("myFuncAfterLoad");

function myFuncAfterLoad() {
    var oldCalendarNotify4a = SP.UI.ApplicationPages.CalendarNotify.$4a;

    SP.UI.ApplicationPages.CalendarNotify.$4a = function () {
        oldCalendarNotify4a();
        myFuncToExpandCalendar();
    }
}

function myFuncToExpandCalendar() {
    try {
        var aTags = document.getElementsByTagName('A');
        for (i = 0; i < aTags.length; i++) {

            if ((aTags[i].evtid == "expand_collapse") && (aTags[i].innerText != "collapse")) {
                (aTags[i]).click();
            }
        }
    }
    catch (err) {
        alert(err.message);
    }
}

</script>

Deux options pour celui-ci. Bâton de l'un ou l'autre des opérations suivantes dans un CEWP.

Le premier va remplacer la fonction qui est utilisée pour déterminer le nombre d'éléments à afficher avant de montrer la développer/réduire les lien. J'ai mis cette à 100 dans l'exemple ci-dessous pour vous assurer que dans mon cas d'utilisation, je n'ai même jamais voir le développer/réduire les boutons et j'ai toujours chaque élément a rendu tout le temps.

<script type="text/javascript">

_spBodyOnLoadFunctionNames.push('WaitForCalendarToLoad');

function WaitForCalendarToLoad() 
{   
    SP.UI.ApplicationPages.SummaryItemRenderer.prototype.$2u = function () 
    {
            ULSvSp: ;
            if (!this.$1A_1) this.$1A_1 = 100;
            return this.$1A_1
        }
}
</script>

La deuxième option remplace le calendrier de l'événement de notification, de sorte que lorsque tous les éléments sont rendus, le script va trouver le premier calendrier de l'instance, et en appel, c'est de développer tous la fonction. Cela permettra de s'assurer que chaque cellule est développée par défaut, mais montrent encore l'effondrement des liens.

<script type="text/javascript">

 _spBodyOnLoadFunctionNames.push('WaitForCalendarToLoad');

function WaitForCalendarToLoad() 
{   
    var old$4a = SP.UI.ApplicationPages.CalendarNotify.$4a;

    SP.UI.ApplicationPages.CalendarNotify.$4a = function () 
    {
        old$4a();

        ctrl = SP.UI.ApplicationPages.CalendarInstanceRepository.firstInstance();

        if (ctrl) {
            ctrl.expandAll();
        }
    }
}
</script>

Donc basé sur l'originalité des solutions fournies par Andrew Peacock (sans doute pour SP2010), j'ai été en mesure de les utiliser en tant que déclarant point de les mettre ensemble une solution de travail pour SP2016.

La grande différence semble être que CalendarNotify est obsolète dans SP2016, ce qui provoque beaucoup de SP2010 solutions basées sur de ne pas travailler dans des versions plus récentes. Ensuite, il y a des complications supplémentaires si l'aide de chevauchement des calendriers; il semble que les éléments de HTML pour des événements sur superposées les calendriers ne sont pas rendus jusqu'à très tard dans le processus de chargement de la page - même en attente sur la dernière source de script sur la page (sp.ui.socialribbon.js) à l'aide de SP.Le GAZON n'a pas attendu assez longtemps pour ceux disponibles. Je crois que c'est pourquoi la plupart, si pas toutes les solutions pour SP2016 calendriers qui s'appuient sur ces cours doivent finir utilisant soit setTimeout() ou la fonction setInterval(). Dans notre cas, pour la deuxième solution, nous devons attendre jusqu'à ce que tout recouvert d'événements qui ont été rendus sur le calendrier avant d'appeler le calendrier de l'expandAll() de la fonction ou il ne fonctionnera pas.

Avec cela dit, ce sont les deux SP2016 compatible avec des solutions je suis venu avec, basé sur l'original SP2010 solutions mentionnées ci-dessus. Le premier supprime la développer/réduire les lien tout à fait et s'assure que le calendrier est toujours développée pour afficher tous les événements.

La première méthode remplace la fonction intégrée qui définit la "effondrement de l'élément de limite" (le nombre d'éléments de la force de la "agrandir/réduire" lien à paraître).

<script type="text/javascript">
    function setCalendarCollapseItemLimit() {
        //Configure the calendar's "collapse item limit" so that it always shows
        //all items by default and never collapses them.
        SP.UI.ApplicationPages.SummaryItemRenderer.prototype.$3V_1 = function() {
            ULSvSp:;
            if(!this.$1B_1) {
                //This sets the "collapse item limit" to 100 events
                this.$1B_1 = 100;
            }
            return this.$1B_1;
        }
    }

    //Call our function once the necessary script is loaded (sp.ui.applicationpages.calendar.js in this case).
    ExecuteOrDelayUntilScriptLoaded(setCalendarCollapseItemLimit, "sp.ui.applicationpages.calendar.js");
</script>

L'avantage de cette méthode est qu'il reste étendu, même si de nouveaux événements sont ajoutés au calendrier après le chargement de la page, sans avoir à manuellement re-développer ou d'actualiser la page. L'inconvénient est que cette solution peut-être besoin la mise à jour après une mise à niveau depuis l'obfuscation les noms de variables peuvent changer (cet exemple a été confirmé travailler w/SP2016 w/la 7/2017 CU - v16.0.4561.1000).

La deuxième méthode appelle le calendrier intégré expandAll() fonction une fois que tous les événements sont affichés. L'avantage de cette méthode est qu'elle laisse la "effondrement" lien disponible pour l'utilisateur afin de réduire le calendrier si vous le souhaitez.

<script type="text/javascript">
    function expandAllCalendarItems() {
        var cal = SP.UI.ApplicationPages.CalendarInstanceRepository.firstInstance();
        if (cal) {
            cal.expandAll();
            return true;
        } else {
            return false;
        }
    }

    //We need to use setInterval() here so that the calendar will be expanded when it becomes available and
    //after any overlaid calendar events have been rendered. An interval of 1400 seems to be sufficient for this.
    //We store the return value so that we can clear it (stop the loop) once we’ve successfully expanded it.
    var expItemsInterval = setInterval(function() {
        var retVal = expandAllCalendarItems();
        if (retVal === true) {
            //Calendar was expanded - clear interval
            clearInterval(expItemsInterval);
        }
    }, 1400);
</script>

Je ne suis pas un grand fan de cette solution, bien que depuis qu'il a quelques gros inconvénients. L'une est que le calendrier va de nouveau s'effondrer si un nouvel événement est ajouté après le chargement de la page. Plus important encore, cependant, est le fait que nous nous reposons sur l'intervalle étant assez longtemps à attendre pour tous superposées les événements de calendrier pour être affiché sur la page (si vous utilisez le calendrier de superposition). Nous avons donc une sorte de condition de course ici; un intervalle de 1400 semble être assez long dans mes tests pour qu'il fonctionne correctement, mais en théorie, si la superposition d'événements prennent trop de temps de calcul, cette solution peut ne pas fonctionner. Si pas de l'aide de chevauchement des calendriers alors cela ne devrait pas être un problème.

Plus la bonne solution serait probablement d'utiliser quelque chose comme un MutationObserver à regarder pour les nouveaux éléments ajoutés à la page (plus précisément, les divs avec une classe de .ms-acal-mdiv), et de l'appeler expandAll() à nouveau si un nouveau est détecté. Cela permettrait également de résoudre le problème de la ré-expansion du calendrier après un nouvel événement est ajouté.

Dans l'ensemble, si "l'effondrement" lien vers l'utilisateur n'est pas nécessaire, je préfère la première solution. Je pense que c'est la plus propre et la plus infaillible, car il ne repose pas sur la fonction setInterval() et travaille à la fois régulier et est recouvert de calendriers.

Grand merci à Andrew Peacock pour les solutions originales ici; ceux qui m'a mis sur la bonne voie pour comprendre ces pour SP2016.

*EDIT: Supprimé le jQuery dépendance depuis qu'il a été inutile, et a ajouté des balises de script autour du code. Ceci devra être réalisé à l'aide de SharePoint Designer, droit en vertu de la PlaceHolderMain tag (à l'aide d'un SEWP ou CEWP serait probablement travailler aussi bien, mais je n'ai pas fait de test à l'aide de ces méthodes).