Lorsque votre équipe de développement a terminé en grande partie une section d'un projet et que certains membres du projet sont dans un état stable, vous pouvez bloquer des membres dans un projet ou une sandbox.

Le blocage d'un membre permet de le placer dans un état qui empêche de modifier les informations sur le membre disponibles dans le fichier du projet. Par exemple, vous ne pouvez pas mettre à jour la révision actuelle ou modifier les attributs d'un membre figé. Le blocage est le contraire de dégel d'un membre.

Le blocage empêche les informations de membre d'être mises à jour, évitant ainsi toute modification par inadvertance des membres figés. Toutefois, le travail de développement peut toujours continuer dans le fichier même du membre. Par exemple, si de nouvelles révisions sont intégrées dans l'archive du membre, Windchill RV&S ne met pas à jour la révision actuelle pour le projet.

Le blocage est utile pour simplifier :

Le blocage évite toute modification des informations de membre dans le projet, mais il n'a aucune incidence sur le fichier du membre en lui-même. Les révisions peuvent toujours être récupérées, modifiées et intégrées, mais aucune modification n'est incluse dans les informations de membre dans le projet.

Vous pouvez modifier l'étiquette ou l'état des membres figés, mais pas leurs attributs. Le blocage peut être utilisé immédiatement avant une opération de point de contrôle pour garantir que personne ne modifie le projet ou ses membres avant la fin du point de contrôle.

Si vous voulez autoriser la modification des membres du projet, vous pouvez les dégeler.

Si un membre est figé, Windchill RV&S signale la disponibilité de nouvelles révisions lors de leur intégration dans l'archive. Windchill RV&S ne met pas à jour le projet en fonction de la dernière révision. De ce fait, la personne appropriée doit décider de dégeler le membre et de mettre à jour l'ensemble du projet.

Voici un exemple de processus de blocage :