I am trying to setup some RSS feeds for our editors, so they can see items in certain workflows. We have three workflows; draft, awaiting approval and approved. However, in workbox we can only see awaiting approval and approved.
What would be the reason for this? I have the correct workflow ticked 'standard workflow'.
This is Sitecore 7.
From what I understood, you have a workflow called Standard Workflow and it has 3 states: "Draft", "Awaiting Approval" and "Approved". And in your workbox, you can only see "Awaiting Approval" and "Approved" states.
Workbox only shows states for which user can execute any command. So e.g. if there is Approve command in Awaiting Approval state and your user has appropriate access rights which allows you to execute that command, then you will see Awaiting Approval state in your workbox. If user cannot execute ANY command in particular state, this state is hidden from the workbox.
Related
I'm using Directory API to fetch users.
Some archived users are returning Suspended = True and others Suspended = False. How can it happen? From my understanding an archived user can't be Suspended.
Moreover, when I look at my admin page both of then are Suspended (image bellow)
Can anyone explain me why this is happening, and if it's normal, is there any risk if an archived user is not suspended?
If you open the image you can see inside the red box that both users are suspended. yes for sure:
"kind":"admin#directory#user",
"id":"10901XXXXXX620",
"etag":"\"SEQQBYC70u6XXXXNYw6b0a5EzY0mTMShjiZga8A/yP85WF6T0tk9a_pgQVEqRq9kHtY\"",
"primaryEmail":"ad....#aaa.com",
"name":{
"givenName":"Aaaa",
"familyName":"John",
"fullName":"Aaaaa John"
},
"isAdmin":false,
"isDelegatedAdmin":false,
"lastLoginTime":"2022-01-10T20:35:25.000Z",
"creationTime":"2020-10-15T22:40:55.000Z",
"agreedToTerms":true,
"suspended":false,
"archived":true,
"changePasswordAtNextLogin":false,
"ipWhitelisted":false,
"emails":[
{
"address":"ad....#aaa.com",
"primary":true
}
],
"languages":[
{
"languageCode":"pt",
"preference":"preferred"
}
],
"customerId":"C00pnlc1u",
"orgUnitPath":"/Suspensos",
"isMailboxSetup":true,
"isEnrolledIn2Sv":true,
"isEnforcedIn2Sv":true,
"includeInGlobalAddressList":true,
"thumbnailPhotoUrl":"https://www.google.com/s2/photos/private/AIbEiAIAAABDCPSAwvv50PWPfSILdmNhcmRfcGhvdG8qKDFhZWFiOTk4NzM5NDY1MjJlOWE4MmE0ODgxMzc3MjM4MzJiYzYyNDUwAUuoUxHJzf7midKhUvdRVmS3n2UE",
"thumbnailPhotoEtag":"\"SEQQBYC70u6XQ2UUjmjNYw6b0a5EzY0mTMShjiZga8A/hU3SJUEhoSHtQtx1ZyG7nXFnWgw\"",
"recoveryEmail":"aaaa#gmail.com"
}```
What you can see in the red box in the screenshots is just the organizational unit where the user has been located in the Admin console, however that is just a name for the OU and does reflect the actual user status.
The user status can be seen below the user's profile picture as you can see in the following screenshot:
As you can see the name of the OU is Test OU Suspended, but the user status is Active so the name of the OU does not reflect the user status.
So in your case this means that the user was archived correctly but is not necessarily suspended. Now to answer your question:
Can anyone explain me why this is happening, and if it's normal, is there any risk if an archived user is not suspended?
You may not need the user to be suspended as it has already been archived. When archiving a user it enters into a partial suspension state where according to the official documentation this is what happens to the archived account:
Can’t sign in to their Google Account, on any system. This includes Google Workspace services, such as Gmail, Google Calendar, and Drive.
Don’t appear in the Global Address List. In user directory listings, the user appears with archived status. Learn about the Global Address List.
Can be deleted or unarchived, but not suspended in the Admin console.
The documentation also mentions the following:
You can archive both active and suspended users. If you unarchive a user, they return to their previous state and regain access to all their previous data.
In conclusion there is nothing wrong if the user is suspended or not, this just means that if an archived user returns True in the Suspended parameter when using the API this is just to save the status it had before being archived so that in case you decide to unarchive it later on it returns back to that specific state.
References:
How AU licensing works
I wanted to understand on the Status Check option that is given in the "Build Policies" in AZURE VSTS. I have gone through the below doc from Azure, but I'm unable to know how do we add the "Status to Check" field, what is it pointing to, what reference should be provided?
https://learn.microsoft.com/en-us/azure/devops/repos/git/pr-status-policy?view=azure-devops
I want to add Sonarqube PR Decoration for all the pull request created, I have also gone through the below document form sonarqube, but unable to get it how exactly its done.
https://sonarqube.kognif.ai/documentation/analysis/azuredevops-integration/#adding-pull-request-decoration-to-azure-devops
Can anyone let me know on this?
how do we add the "Status to Check" field, what is it pointing to, what reference should be provided?
Please follow below steps.
Create a build pipeline using this repository and specify its master branch.
Please follow this doc: Deploy pull request Artifacts with Azure Pipelines to configure your release pipeline using this build pipeline.
Set up the branch policies and set this build pipeline as the Build Validation.
Create a test pull request to trigger this build pipeline, and then the successful build will trigger a pull request release and then the release is deployed to the specified environments, and the status of the deployment is displayed in the PR page.
Select Add status policy in the branch policies and select a status policy from the status to check dropdown menu. The dropdown contains a list of recent statuses. Everything is done.
Now you should know how to add Sonarqube PR Decoration as the status policy in the branch policies for all the pull request. See video: Azure DevOps Pull Request/Branch Decoration with SonarQube for more details.
I want to test out the Sample Workflow in Sitecore 8. This is what I have done so far:
Insert the sample workflow in the standard values of the template
Created two test users: Test Editor and Test Approver
Created two roles: SubmitionRole and ApprovalRole
In Security Editor I assigned Read, Write access including the 3 workflow rights to the Draft state for the SubmitionRole role and assigned this role to Test Editor
In Security Editor I assigned Read, Write access including the 3 workflow rights to Awaiting Approval and and Approved states for the ApprovalRole role and assigned this role to Test Approver
Then I created an item from that template with the Test Editor and the item went into the Draft state. So I submitted the item in the Workbox.
Now when I log in with the Test Approver, there's nothing in the Workbox. I can see the Workflow and its Approval State in the Workbox, but there's nothing inside it. As admin I can see the item waiting in the Approval state.
Here is a screenshot of the Access Viewer for the Test Approver:
What am I missing here?
Ensure that your user/role has language read and write access to the relevant item languages located under /sitecore/system/Language. The Language Read and Language Write are a separate set of fields which you can expose in the Security Editor by selecting them from the "Columns" option. The content approval role needs both Language Read and Language Write on the relevant language items:
You don't need to assign Write access to the workflow state items (Awaiting Approval and Approved). This means that ApprovalRole is allowed to edit those items, not items in that state.
What you need to set is:
Workflow State Write for the Awaiting Approval state (controls whether or not a user can update items which are currently associated with a specific workflow state)
Workflow Command Execute for the commands below Awaiting Approval state which should be allowed for the role (controls whether or not a user is shown specific workflow commands)
Write access to the item itself (the one that was submitted from the Draft state to the Awaiting Approval state).
And that should be it.
.
In my Sitecore workbox, there are several workflow states being displayed. (Draft, Awaiting, Approved)
How can I restrict acess only to one/few(Draft) workflow states for a particular role (e.g. Junior Manager) in Sitecore?
(I m using v6.5)
Yes, you can. To be able to see the various workflow states you'll need read access to that workflow state as well as write access to the item you want to approve/ reject.
From the Workflow Cookbook (chapter 3.1 and 3.2):
3.1The Content Editor and Workbox only displays workflow commands for
non-Administrator users when: The user has write access to the
associated item. and The user has write access to the command’s parent
workflow state. and The user has read access to the workflow command
itself.
3.2 Users who have read access to a workflow state can see that state in
their workbox as long as the state includes workflow commands for
which they have command execute access rights. If business
requirements state that a particular workflow state should be hidden
from a given set of users, you can restrict access to that state for
those users by: Hiding all the workflow commands in the state from the
users in question. or Explicitly hiding the workflow state itself from
the users in question. To explicitly hide a workflow state: Turn off
the inheritance access right for the workflow state item and do not
grant read access to the workflow state to the user and all the roles
assigned to the user. or Deny the user or one of the roles that the
user is assigned read access to the workflow state item.
We have the Publish Agent set to run every 15 minutes with 'Incremental Publish'. Sitecore client users 'Check In' and 'Approve' an item in Sitecore to queue the item. They can also do a manual publish if required to make something live immediately. We are seeing some issues where some of the items that are checked in and approved through the workflow are not getting picked up by the scheduled publisher. Also, when the user tries to publish from the publish tab the parent publishes but not the child items. The child items have to be published one at a time.
To me the issue seems to be that these approved items are not getting added to the publishing queue. But I am not certain of this.
We installed a module called 'Publishing Status Manager' which basically shows a Sitecore user the various publish operations that are active or in queue. This problem started occurring after that module was installed. I am not sure if that is the cause of this issue though.
I am looking for some suggestions/advice on where to look and how to fix this issue.
Items that are in the final workflow step is always added to the publish queue. I guess your issue revolves around the fact that the items in the workflow is not in the final workflow step. Please ensure that the actually reaches this state.
If you would like to check what's in the publish queue, read this article:
http://briancaos.wordpress.com/2011/06/16/sitecore-publish-queue/
You must use the code as described in "THE CURRENT VIEW" as it tells you what is published next time an incremental publish is executed.
Also, ensure that the publish agent publishes the current targets and correct languages:
<agent type="Sitecore.Tasks.PublishAgent" method="Run" interval="00:00:00">
<param desc="source database">master</param>
<param desc="target database">web</param>
<param desc="mode (full or smart or incremental)">incremental</param>
<param desc="languages">en, da</param>
</agent>
It was just the module that we installed that over wrote the publishing pipeline
Publish agent will not pick up queued item if value of publishing.checksecurity is true in web.config. You can make this value as false. Or else create a user, give it proper access rights and override the agent to switch the user.