I can do them per-project (select project, Settings, Versions), but not globally. How do I list all versions that exist?
to list all versions you need to do minimum one "shared" version. Hint: You can do it with "blocked" status.
The page redmine/issues (assuming redmine is your server) shows all issues. You can show versions then sort on that column. It appears to sort versions by earliest due date followed by those with no version. You can also "group results by" and select versions.
However this isn't great if you have lots of bugs. And it doesn't show more information such as the due date of the version.
Related
Does RAZL can compare Sitecore 6.5 (core,master,web) databases with Sitecore8.1(core,master,web) databases.
Or it can compare only same versions of Sitecore.
I need to use this for a migration from Sitecore 6.5 to Sitecore 8.0
Yes it can.
But keep in mind that using RAZL is not a recommended practice for Sitecore upgrades. Why? There are plenty of reasons. Some of them can be found in this article:
The Truth About Sitecore Upgrades
I agree.
I have used RAZL in the past for moving the content. You can use this to move content from one Sitecore instance to another one even on different versions, but I would not recommend it using for Sitecore migration because you may move the content without properly moving dependencies first. This tool is good if you want to move very heavy content without too much of definition changes or you can use RAZL for comparison.
Using Redmine v3.3, is it possible to have a custom calculated field based on data in two other custom fields?
e.g. Duration = Date 2 - Date 1
Specifically, I am attempting to calculate the days between two dates as a performance metric. More generally, we will be looking to eventually using other custom calculated fields (simple additions, multiplications, etc.).
It would be preferable to keep this to the "vanilla" Redmine v3.3 without additional plugins but all suggestions are of course welcome.
Not in Vanilla Redmine as of 3.3, unfortunately.
It has been requested and there was some discussion about it. The feature wasn't rejected but nobody has gotten around to building it for Redmine. You can follow the discussion/development here:
http://www.redmine.org/issues/1712
A plugin is discussed in that issue as well but - as with all plugins - a thorough check will be required if it matches your stability/security expectations.
Such feature request has been filed 11 years ago (2008-7-30), while not yet enhanced.
At the moment, you can try Computed Custom Field plugin.
Although it shows "This project is no longer maintained", it stated that it is comptatible with latest stable version of Redmine 4.0.4 (2019-06-10).
Current version: 1.0.7 (2019-01-14)
Compatible with: Redmine 4.0.x, 3.4.x, 3.3.x, 3.2.x, 3.1.x, 3.0.x, 2.6.x, 2.5.x
I've been wondering if anybody knows why the Presentation Details (stored in the Renderings field) are shared across all languages and versions by default?
I had confirmed this was the intended behaviour of 'shared' field with these links:
This SO post:
In Sitecore, when adding a field to a template, there's a checkbox called "shared". What's it for?
And this SDN resource:
http://sdn.sitecore.net/sdn5/reference/sitecore%205,-d-,3/field%20reference/field%20properties/data%20properties.aspx
The situation
As an author, I have created a new page and pushed it through workflow approval. Everything is great, and the page is published. The next day, I want to make some changes so I open up Page Editor, a new version is created, and I start adding and removing components on the page.
The problem
As soon as I hit save, the approved and published version of my page is also affected. The history of my previous layout is gone. As soon as a Site Publish is executed by somebody (or a scheduled PublishAgent executes) my page in the Web database will be updated.
Sure, the datasource of my new components that I added may not be published yet, but what if I added an existing datasource that was already approved? My removals also are immediate.
The desired goal
I'd like to be able to version these changes, and changing the field to no longer be shared seems like the right way to go. In my case, with a unilingual site, this won't impact the multilingual aspect of it.
Does anybody know why this field is shared across versions? If I unshare it, am I completely breaking the upgrade path?
I've just been "having a chat" with Sitecore support on this very issue. The concensus seems to be - paraphrasing what they said a bit - "We think it'll be fine if you change it. You should test it thoroughly, rendering deltas, page editor Work and so on".
I can add a few comments of my own; unchecking "shared" on __renderings, does appear to Work. At least at the initial glance. I've heard about this being done in solutions before and I've never heard any ill effects come from it.
And yet; whenever you mention it; you get a LOT of nervous responses and comments like "you really shouldn't be messing with Sitecore standard setup". And while a valid point indeed, I'd like to add a point of my own to this debate:
Given that, from an API perspective, there is very few things that are different when reading a field value from a "shared" field as opposed to a versioned one - I also believe there are very few potential cases where "unsharing" it would pose a problem.
Or in other words - I consider it low risk. But I've never had a real life solution running in a live environment either, with this setting changed :-)
I'm sorry, but I don't have a direct answer to your question - WHY Sitecore set it up like this, I belive to be part of Sitecore's heritage: The idea that multiple language versions of a site should be just "layered" versions of the exact same pages and therefore presentation details might as well be shared - presumably for some performance gain. I am not entirely convinced this vision still quite holds today - where editors daily "page edit up" new components on new versions, and set up special sale banners and related content weeks in advance.
I completely agree with and am thankful for the Mark Cassidy March 3 2014 answer to this. Since then, in Sitecore 8.0 they added "Versioned Layouts".
See:
https://dev.sitecore.net/en/Downloads/Sitecore%20Experience%20Platform/8%200/Sitecore%20Experience%20Platform%208%200/Release%20Notes "Versioned layouts – a different presentation set on different versions of different languages for the same item".
nice post: http://jockstothecore.com/sitecore-8-versioned-layouts-mixed-feelings/
This is the default behavior of sitecore as you mentioned in the post. Its not always good practice to change that. This topic has been dicussed earlier which might help you
Setting __Renderings field not shared in Sitecore consequences?
Here is a blog post about considerations for doing this:
Unsharing the Layout field in Sitecore - a multi-language strategy
That said, I've worked on a project where our client went in and did this themselves. It caused problems. As I recall, they unshared the __renderings field and all prior versions lost their presentation settings. Also, other languages other than the selected one also lost their settings. We had to do a DB restore and get things back and told them never to do that again. If you are considering this, read the blog post about, and do some isolated dry runs as it may expose issues you weren't aware of (e.g. impacting other languages, old versions, etc.).
We are currently running Sitecore CMS 6.5 (120706) with the shared source Item Buckets module installed from here:
https://github.com/jerrong/Sitecore-Item-Buckets/tree/master/sitecorepackages/ItemBuckets%206.5%20NET_40/Final
We wish to upgrade to CMS version 7.0. I'm told that there is currently no upgrade path and to expect one in a few months. However we would prefer not to have to wait on this.
Item buckets is used only for a single section of our site. Everything else is delivered via the standard content tree.
We have tried upgrading to 6.6 first as required by the documented upgrade procedure, despite it mentioning later in the instructions that the shared source item buckets module is unfortunately unsupported for upgrade. Confirmed that this definitely does not work, we receive the error:
Exception Details: System.IO.FileLoadException: Could not load file or assembly 'Lucene.Net, Version=2.3.1.3, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
We also tried disabling Item Buckets by removing the .config files etc. but we had further problems, presumably because of the actual content/data template changes that were made by the Item Buckets update.
We are thinking of trying a clean install of CMS 7.0, and then migrating our custom code base, items in the content tree (including data templates, layouts, renderings, etc) with Sitecore packages to work around the issue.
Can someone validate this approach, or better still suggest a much less painful solution!?
Many Thanks
(this is not official Sitecore advice as that is still being worked on disclaimer,disclaimer!)
Some ideas that might help ..
First we need to work on the data side of things (forget front end code for a second)
You could Un-bucket your items so that they are again plain Sitecore items. You could then remove the item bucket module templates and fields as you mentioned before (by 'unbucketing' you should now have no reliance on the bucketing templates etc.)
You could also look at creating an 'anti-package' using Sitecore Rocks, either way this should give you a site closer to a site before the item buckets module.
You could then get a base/clean install of 6.5 (120706) and then compare it to your working copy 'master' database using a tool like Sitecore Courier.
Sitecore Courier - https://github.com/adoprog/Sitecore-Courier - Allows you to compare 2 versions of Sitecore DB against each other and make an update package of that difference.
This should make you an update package of all the changes that have been made to your 'master' database so that you can, in theory, install this into a fresh copy of Sitecore.
You could see how far this gets you when you install this update package, in theory then you can re-bucket your section that used the old buckets module but using the new built-in buckets.
Front-end code wise, the old item buckets modules way of accessing the search has been completely re-written as that it now uses Linq To Sitecore. Hopefully this will be easier to migrate and the buckets will still work in largely the same way (hopefully better hehe!)
Like Ruud I would be interested to hear about others techniques for doing this.
Any extra complexity could come from thing like :
1) How much customisation of the core database you have done
2) How many new field types and XAML applications you may have written
At this point, there is no good solution for this yet.
If you are actively using the module, there is no way to upgrade right now (not that I know of).
If you are not using the module at all, you can remove everything in Sitecore that has to do with ItemBuckets.
This is a manual job for now... (I've done this with success in a 6.5 environment).
To be sure you remove everything, open the item buckets installation package (the ZIP file) to see what items are installed and manually remove all those items from Sitecore (this will include templates, fields, field types, settings).
You can also use the search in the content editor to search for "itembucket" or "item bucket" and find related items that way.
Another way is to search with SQL directly in the master and core database.
Once you have removed everything in Sitecore and configuration that is related to the buckets, rebuild the link database and run a database cleanup (from control panel) and you should be good to go.
It's a dirty job...
If anyone has a better way, I'd love to hear about it!
the problem you are having there is that the item buckets code was compiled against Lucene.Net 2.9 and Sitecore 7 has v3.0.3.
You could add an assembley binding in in the web.config configuration/runtime section that maps the old version to the new and then fix any issues you get with deprecated methods etc...
You will probably also want to remove the Item Buckets module before the upgrade as suggested as the new bucket templates & items may conflict with the shared source versions. You would at least need to remove the Item buckets config and dll's from the bin folders as these could also conflict.
I don't think there is a simple way of doing it yet or Sitecore would have given out an upgrade path already.
I have a Sitecore 6.5 project, where I have upgraded all the content from an earlier version. But something seems to have gone wrong in the upgrade process, which has caused all items to have a security setting of extranet\everyone which have deny read access, even though that is not the case. Also the layout and insert options needs to get reset and taken the values from the templates standard values.
I could do this manually in the Sitecore UI, but that would take quite some time, as there is 3000+ items.
Is there any way I can patch this with a quickfix of some sort?
You could either write a script in ASPX that does this for you or install the PowerShell module and script it with that.
It depends on your experience and on which tools you have available.
Unfortunately there is no built-in method for resetting layouts and insert options on all content items.