We have workflows enabled for majority of our content in Sitecore. We are using the auto-publish feature available after an item gets into the Final state of the workflow. Our implementation partner has enabled 3 parameters for this publish action -
alllanguages=1
related=1
deep=1
I understand that deep publishes only the children of the item that the workflow is on. I also understand that related will publish all related images, items are linked via the link manager functionality. But I do not understand what the alllanguages parameter is for. Does this publish the item in the workflow in all available languages? Also, would it publish all children and related items in all available languages as well?
There are 6 parameters boolean, 1 or 0
With allanguages, related and deep, it publish the current item and childeren and related items in all languages so also the childeren and related are published in all languages.
See this article auto-publish-workflow-action-updates
This are the language options:
"alllanguages" - controls whether current item will be published in all languages that exist in source database. Possible values: "1" - current item will be published in all languages that exist in source database; all other values - code uses values of other parameters to determine languages in which current item will be published.
"languages" - comma (,) separated list of languages in which current item will be published.
"itemlanguage" - controls whether current item will be published in its current language. Possible values: "1" - current item will be published in its current language; "0" - current item will not be published in its current language; all other values - current item will published in its current language. Note that even if value of this parameter is "0", current item will still be published in its current language if current language of the item is in "languages" list.
Sitecore has versions and languages for each item; My assumption (without seeing the implementation) would be it publishes all (available) versions of said items. That is to say, if you only had an en-US language version, you wouldn't necessarily get an es-SP too (unless part of your workflow is a language translation).
Related
I have a list in Microsoft List that is used as a tracking tool for work management. We have status, category of issue, people to be assigned, due date.
To track KPIs, we need to have some sort of export (csv) with the infos that can be found in version history of each item of the list.
For instance, we need to know how many items have been in status "published" in november, how many in october, etc.
How many have been modified by "..." and by "..."
And the most important indicator would be the number of days until an item has been open -> closed. By "open" I mean created. By "closed" I mean the last modification done on it .
NB : We don't have Power Automate but we can use Power BI
I tried the basic CSV export, it only has the column from my list, nothing else.
I found an article that can export SharePoint List Item Version History to Excel using PowerShell.The reference code in the article below can export the creator and creation time of each version, and you can also add other fields as needed.
Reference: https://www.sharepointdiary.com/2014/06/sharepoint-version-history-export-to-excel.html
Want to restrict to publish items ,if items count is more than 20.
You could do this with an item validator, so that "the 21st" item and onward would fail validation so that it cannot transition to the final workflow step.
Another, more intrusive, alternative could potentially be having a item:saved processor that could set __Never publish to 1 to the surplus items, so they can't be published.
As a general recommendation, I'd say you should avoid changing the publishing pipeline. Try having all the items in a "good/valid" state instead, like the solutions above, where you don't change the behavior of Sitecore - rather just keep the content in a state that's in line with the application requirements.
I'm trying to figure out how to know when an Item was published in Sitecore. I've looked at the History table in SQL Server and I see when the Item was changed, and also when it moved through every step in the workflow. But I don't see anything that looks like a "Publication" event.
Thanks...!
Unfortunately you can't get a published date. You need to implement a custom way to track when items are published.
Please check this blog post:
http://sitecoreskills.blogspot.ro/2014/04/first-and-last-publish-dates-in-sitecore.html
If tracking the item published date using the History Table, note that the History Table is cleaned-up every 4hrs by default. So, you may end up having no values for the item.
Normally, once an item has been modified, it is inserted into the publish queue table. You may instead track the last published that occurred. You may refer to my blog post: https://hishaamn.wordpress.com/2015/10/25/last-published-timestamp-on-sitecore-login-page/
Thanks
We currently have a CRM Dynamics 4.0 system and as part of our Account Entity we have a field new_accountstatus with the following set up:
Schema
Display Name: Account Status
Name: new_accountstatus
Requirement Level: No Constraint
Searchable: Yes
Description: "V1.0"
Type
Type: Picklist
Overdiew 2. Active 3. Suspended 4.De-Energise 5.Terminated 6.Inactive
Default Value: Unassigned Value
We are contemplating upgrading and moving to CRM Online 2015 and have created an online trial and as part of the initial configuration we are trying to set up account model and the picklist with similar values and layout.
On creating a new field in CRM 2015 online I can see that the Data Type fields have completely changed. And from the available list Option Set was seemed the most relevant for my needs.
Can anyone explain to me what the Field Type of Simple and Calculated is all about? Also if I try to enter the same values as was in our old system of between 1-6 I get the message:
"The option value you specified does not use this solution's option value prefix (10,000). You should enter a number between 100,000,000 and 100,009,999"
If I enter this as 10,000,001 will this then be read as 1 from the option set as would have been the case in dynamics 4.0 picklist?
The type you need for your picklist is Option Set.
From CRM 2011 you can choose between local and global (existing) Option Set. If your picklist is used only inside account entity you can create it as local, if it is used in more than one entity (or you plan in the future that this is a possibility) you can create it as global, in order to be reused.
The difference between Simple and Calculated is a feature introduced with CRM 2015, in your case you need Simple (Calculated is in case the value becomes from a calculation, more details here: http://blogs.technet.com/b/lystavlen/archive/2014/11/20/calculated-fields-new-in-crm-2015.aspx)
Regarding the value (1-6). CRM 2011 introduced the concept of Solutions and Publishers, each Publisher can have an Option Set prefix (10000 is the value for the Default Publisher) in order to differentiate Option Set coming from different solutions.
You can still override the prefix, so you can put the values 1-6 if you prefer, the use of the prefix is suggested but not mandatory. the value 100,000,001 is different from 1, so (considering backward compatibility with external system) you should put 1 as value.
Taking the example of the Sample Workflow in SiteCore, in the Approving state state, can I add a new Reject option for the approver to reject the item and move it to the reviewing state?
I believe that the default reject action in any state will always move the item back to the first/draft state but we are implementing a workflow with multiple states in it and the approver would like to have the option to reject to the various teams which each have a state in the workflow. So, is it possible to have multiple reject options as well - for example, can the approver reject to draft or to reviewing based on the error detect?
Select the 'Reject' item underneath your approving workflow step, then set the 'Next State' field to point to the correct workflow state.
In order to have the choice to reject to multiple different states, you will need to add multiple reject buttons. Simply duplicate the Reject "Command" item, point each items "Next State" field to a diff state, and then rename the "Command" items accordingly so the user knows what they mean. E.G. "Reject to Draft" and "Reject to Reviewing".