Can I delete the default Tridion SDL groups?

Question

I assumed that there was something unique or special about the default Tridion groups (e.g. editor, editor in chief, etc.), since creating a new publication seemed to automatically get these groups.

I really see that all groups in the designated parent receive new publications when they are created, this is not necessary because they are the default groups.

Can I delete these groups by default? Besides ready-made workflow options, any reason to leave them in Tridion from a programming or technical point of view?

Answer 1

No, it is not possible to delete a predefined group - you will always receive an error message.

I can’t talk about the reasons for this, but I think that the fact that they are used for new publications is at least part of the reason.

However, you are not required to use them.

Answer 2

New publications outside the existing BluePrint will receive default rights from the default groups. If you do not need any settings, you should remove them (but I never tried, so this may not be possible). They have a special flag in the database (IS_DEFAULT_GROUP).

I tend to use them to control rights and make my other groups members of authors and editors, etc., so that I get some basic rights out of the box for all publications.

Answer 3

In the original R5 security design, it was possible to remove the predefined groups, and that was intentional. If you get a specific message that this is not possible, then this restriction should be added later, presumably since the code was rewritten in 2011.

The idea in R5 was that predefined groups would offer a good “ready-made” experience and keep people in some configuration. (And, of course, she suggested backward compatibility with R4.) Other functions repeated this: for example, if you create a publication in a project, the rights of predefined groups are cloned from the parent publication. For groups that you created yourself, this does not happen. In the end, if you chose the security setting, it is reasonable to expect that you yourself will configure everything yourself, right?

I cannot think of a good reason to prevent their removal. Perhaps someone thought the “custom” approach was too unfriendly, but I'm thinking. (Does anyone know the true reason?)