Default Security Rights for New Publications
When you create a new publication, Tridion applies some sensible default rights for the built in groups like Editor and Chief Editor. We built our security model on top of these default groups, so when we create new publications, the only configuration we have to do with regards to authorization is to alter the group scope to include the new publications.
The exception to this seems to be rights for optional modules like Translation Manager. It seems like we always have to manually add this right to the required groups for each new publication, which is is bit of a pain.
Looking at the docs, this does not seem possible, but I thought I would check anyway: Is there some way to also define defaults for these additional rights which come from optional modules so we don't have to keep doing this? We are using SDL Web Cloud (8.6)
user-rights
add a comment |
When you create a new publication, Tridion applies some sensible default rights for the built in groups like Editor and Chief Editor. We built our security model on top of these default groups, so when we create new publications, the only configuration we have to do with regards to authorization is to alter the group scope to include the new publications.
The exception to this seems to be rights for optional modules like Translation Manager. It seems like we always have to manually add this right to the required groups for each new publication, which is is bit of a pain.
Looking at the docs, this does not seem possible, but I thought I would check anyway: Is there some way to also define defaults for these additional rights which come from optional modules so we don't have to keep doing this? We are using SDL Web Cloud (8.6)
user-rights
add a comment |
When you create a new publication, Tridion applies some sensible default rights for the built in groups like Editor and Chief Editor. We built our security model on top of these default groups, so when we create new publications, the only configuration we have to do with regards to authorization is to alter the group scope to include the new publications.
The exception to this seems to be rights for optional modules like Translation Manager. It seems like we always have to manually add this right to the required groups for each new publication, which is is bit of a pain.
Looking at the docs, this does not seem possible, but I thought I would check anyway: Is there some way to also define defaults for these additional rights which come from optional modules so we don't have to keep doing this? We are using SDL Web Cloud (8.6)
user-rights
When you create a new publication, Tridion applies some sensible default rights for the built in groups like Editor and Chief Editor. We built our security model on top of these default groups, so when we create new publications, the only configuration we have to do with regards to authorization is to alter the group scope to include the new publications.
The exception to this seems to be rights for optional modules like Translation Manager. It seems like we always have to manually add this right to the required groups for each new publication, which is is bit of a pain.
Looking at the docs, this does not seem possible, but I thought I would check anyway: Is there some way to also define defaults for these additional rights which come from optional modules so we don't have to keep doing this? We are using SDL Web Cloud (8.6)
user-rights
user-rights
asked Dec 12 '18 at 8:42
Will Price
12.9k1558
12.9k1558
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Is there some way to also define defaults for these additional rights which come from optional modules so we don't have to keep doing this?
Not that I know of.
It seems like we always have to manually add this right to the required groups for each new publication, which is is bit of a pain.
You could utilize the Event System system to set these right. The way to do it is through the Repository.AccessControlList
property.
1
Yep, I agree with you probably having to do this through the Events System. Rights for the additional modules (Translation, etc.) tends to be done through App Data on the Publication, rather than the normal Publication properties though, so you'll have to do some XML creation/manipulation.
– Jonathan Williams
Dec 12 '18 at 11:00
Good point on the App Data, totally slipped my mind (I remember schema fields' translatable options also being set in App Data)
– Atila Sos
Dec 12 '18 at 11:12
Technically speaking, the default Publication rights are “configured” in a DB table (DEFAULT_REPOSITORY_RIGHTS
), but there is no public API to change those. So, +1 for Event System.
– Rick Pannekoek
Dec 13 '18 at 7:18
add a comment |
In the past, (where the client had a tool to create new publications with specific blueprint setups depending on selected options) we added a simple extension to select 'default' permissions (that would ideally have been inherited) and then options to override them (if you were a member of a specific user group) - all interacting through the Core Service obviously.
You'll not be far wrong looking at the Powershell modules as a starter.
For an example of how to set rights/permissions from the Powershell... blog.indivirtual.nl/…
– Dominic Cronin
Dec 15 '18 at 18:57
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "485"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftridion.stackexchange.com%2fquestions%2f19576%2fdefault-security-rights-for-new-publications%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Is there some way to also define defaults for these additional rights which come from optional modules so we don't have to keep doing this?
Not that I know of.
It seems like we always have to manually add this right to the required groups for each new publication, which is is bit of a pain.
You could utilize the Event System system to set these right. The way to do it is through the Repository.AccessControlList
property.
1
Yep, I agree with you probably having to do this through the Events System. Rights for the additional modules (Translation, etc.) tends to be done through App Data on the Publication, rather than the normal Publication properties though, so you'll have to do some XML creation/manipulation.
– Jonathan Williams
Dec 12 '18 at 11:00
Good point on the App Data, totally slipped my mind (I remember schema fields' translatable options also being set in App Data)
– Atila Sos
Dec 12 '18 at 11:12
Technically speaking, the default Publication rights are “configured” in a DB table (DEFAULT_REPOSITORY_RIGHTS
), but there is no public API to change those. So, +1 for Event System.
– Rick Pannekoek
Dec 13 '18 at 7:18
add a comment |
Is there some way to also define defaults for these additional rights which come from optional modules so we don't have to keep doing this?
Not that I know of.
It seems like we always have to manually add this right to the required groups for each new publication, which is is bit of a pain.
You could utilize the Event System system to set these right. The way to do it is through the Repository.AccessControlList
property.
1
Yep, I agree with you probably having to do this through the Events System. Rights for the additional modules (Translation, etc.) tends to be done through App Data on the Publication, rather than the normal Publication properties though, so you'll have to do some XML creation/manipulation.
– Jonathan Williams
Dec 12 '18 at 11:00
Good point on the App Data, totally slipped my mind (I remember schema fields' translatable options also being set in App Data)
– Atila Sos
Dec 12 '18 at 11:12
Technically speaking, the default Publication rights are “configured” in a DB table (DEFAULT_REPOSITORY_RIGHTS
), but there is no public API to change those. So, +1 for Event System.
– Rick Pannekoek
Dec 13 '18 at 7:18
add a comment |
Is there some way to also define defaults for these additional rights which come from optional modules so we don't have to keep doing this?
Not that I know of.
It seems like we always have to manually add this right to the required groups for each new publication, which is is bit of a pain.
You could utilize the Event System system to set these right. The way to do it is through the Repository.AccessControlList
property.
Is there some way to also define defaults for these additional rights which come from optional modules so we don't have to keep doing this?
Not that I know of.
It seems like we always have to manually add this right to the required groups for each new publication, which is is bit of a pain.
You could utilize the Event System system to set these right. The way to do it is through the Repository.AccessControlList
property.
answered Dec 12 '18 at 9:24
Atila Sos
2,7432720
2,7432720
1
Yep, I agree with you probably having to do this through the Events System. Rights for the additional modules (Translation, etc.) tends to be done through App Data on the Publication, rather than the normal Publication properties though, so you'll have to do some XML creation/manipulation.
– Jonathan Williams
Dec 12 '18 at 11:00
Good point on the App Data, totally slipped my mind (I remember schema fields' translatable options also being set in App Data)
– Atila Sos
Dec 12 '18 at 11:12
Technically speaking, the default Publication rights are “configured” in a DB table (DEFAULT_REPOSITORY_RIGHTS
), but there is no public API to change those. So, +1 for Event System.
– Rick Pannekoek
Dec 13 '18 at 7:18
add a comment |
1
Yep, I agree with you probably having to do this through the Events System. Rights for the additional modules (Translation, etc.) tends to be done through App Data on the Publication, rather than the normal Publication properties though, so you'll have to do some XML creation/manipulation.
– Jonathan Williams
Dec 12 '18 at 11:00
Good point on the App Data, totally slipped my mind (I remember schema fields' translatable options also being set in App Data)
– Atila Sos
Dec 12 '18 at 11:12
Technically speaking, the default Publication rights are “configured” in a DB table (DEFAULT_REPOSITORY_RIGHTS
), but there is no public API to change those. So, +1 for Event System.
– Rick Pannekoek
Dec 13 '18 at 7:18
1
1
Yep, I agree with you probably having to do this through the Events System. Rights for the additional modules (Translation, etc.) tends to be done through App Data on the Publication, rather than the normal Publication properties though, so you'll have to do some XML creation/manipulation.
– Jonathan Williams
Dec 12 '18 at 11:00
Yep, I agree with you probably having to do this through the Events System. Rights for the additional modules (Translation, etc.) tends to be done through App Data on the Publication, rather than the normal Publication properties though, so you'll have to do some XML creation/manipulation.
– Jonathan Williams
Dec 12 '18 at 11:00
Good point on the App Data, totally slipped my mind (I remember schema fields' translatable options also being set in App Data)
– Atila Sos
Dec 12 '18 at 11:12
Good point on the App Data, totally slipped my mind (I remember schema fields' translatable options also being set in App Data)
– Atila Sos
Dec 12 '18 at 11:12
Technically speaking, the default Publication rights are “configured” in a DB table (
DEFAULT_REPOSITORY_RIGHTS
), but there is no public API to change those. So, +1 for Event System.– Rick Pannekoek
Dec 13 '18 at 7:18
Technically speaking, the default Publication rights are “configured” in a DB table (
DEFAULT_REPOSITORY_RIGHTS
), but there is no public API to change those. So, +1 for Event System.– Rick Pannekoek
Dec 13 '18 at 7:18
add a comment |
In the past, (where the client had a tool to create new publications with specific blueprint setups depending on selected options) we added a simple extension to select 'default' permissions (that would ideally have been inherited) and then options to override them (if you were a member of a specific user group) - all interacting through the Core Service obviously.
You'll not be far wrong looking at the Powershell modules as a starter.
For an example of how to set rights/permissions from the Powershell... blog.indivirtual.nl/…
– Dominic Cronin
Dec 15 '18 at 18:57
add a comment |
In the past, (where the client had a tool to create new publications with specific blueprint setups depending on selected options) we added a simple extension to select 'default' permissions (that would ideally have been inherited) and then options to override them (if you were a member of a specific user group) - all interacting through the Core Service obviously.
You'll not be far wrong looking at the Powershell modules as a starter.
For an example of how to set rights/permissions from the Powershell... blog.indivirtual.nl/…
– Dominic Cronin
Dec 15 '18 at 18:57
add a comment |
In the past, (where the client had a tool to create new publications with specific blueprint setups depending on selected options) we added a simple extension to select 'default' permissions (that would ideally have been inherited) and then options to override them (if you were a member of a specific user group) - all interacting through the Core Service obviously.
You'll not be far wrong looking at the Powershell modules as a starter.
In the past, (where the client had a tool to create new publications with specific blueprint setups depending on selected options) we added a simple extension to select 'default' permissions (that would ideally have been inherited) and then options to override them (if you were a member of a specific user group) - all interacting through the Core Service obviously.
You'll not be far wrong looking at the Powershell modules as a starter.
edited Dec 13 '18 at 11:13
answered Dec 12 '18 at 9:24
Dylan .. Mark Saunders
7,2481132
7,2481132
For an example of how to set rights/permissions from the Powershell... blog.indivirtual.nl/…
– Dominic Cronin
Dec 15 '18 at 18:57
add a comment |
For an example of how to set rights/permissions from the Powershell... blog.indivirtual.nl/…
– Dominic Cronin
Dec 15 '18 at 18:57
For an example of how to set rights/permissions from the Powershell... blog.indivirtual.nl/…
– Dominic Cronin
Dec 15 '18 at 18:57
For an example of how to set rights/permissions from the Powershell... blog.indivirtual.nl/…
– Dominic Cronin
Dec 15 '18 at 18:57
add a comment |
Thanks for contributing an answer to Tridion Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftridion.stackexchange.com%2fquestions%2f19576%2fdefault-security-rights-for-new-publications%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown