UX improvement: Content deployment

[MikeKry]

Is your feature request related to a problem? Please describe.

Related to #9023, which actually describes bug, but this one is improvement idea.

We have been using deployment plans a lot to sync content between stage and prod environment and came to some issues described in #9023.

There is also one thing, that I think would be very useful - adding new content item status, something like "Ready for deployment", which would mean that it is part of selected deployment plan.

I can imagine an potentially easy solution:

• Create new deployment step, that allows to export items by selected taxonomy
• Create setting, that would allow to show taxonomy value in content item list (or provide a way to extend content item list display without overriding default view) e.g. like this or some way to customize all labels in content item display..

Use case could be like this:

• Admin creates new taxonomy, e.g. DeploymentStatus, with values "Needs review, Deploy to preprod, Deploy to prod"
• Content manager can set these values to content items and instantly sees them in content item list and can filter them by taxonomy. This makes it a lot easier to publish content to other instance.

[deanmarcussen]

Yes, we talked about doing something like a queue for deployment, when I wrote the related features, but it was dropped in favour of keeping it simple.

That doesn't mean it isn't worth revisting, so have a go and see what you come up with!

Taxonomies do sound like the way to go for your scenario.

It would be simple enough to create a deployment source for that read content items based on the taxonomy value.

To extend the summary admin view to display taxonomy tags you can use a little placement, and a view. (and a differentiator for the particular taxonomy field you want. / part name that you put it on etc)

    "TaxonomyField" : [
        {
            "place": "Content:20",
            "displayType" : "SummaryAdmin"
        }
    ],

and a view called TaxonomyField.SummaryAdmin.cshtml

@model OrchardCore.Taxonomies.ViewModels.DisplayTaxonomyFieldViewModel
@foreach (var contentItemId in Model.TermContentItemIds)
{
    var term = await Orchard.GetTaxonomyTermAsync(Model.TaxonomyContentItemId, contentItemId);
    @if (term != null)
    {
        <span class="badge badge-secondary font-weight-normal" title="@term">
            <i class="fas fa-tag fa-xs fa-rotate-90 align-middle" aria-hidden="true"></i> @term
        </span>
    }
}

One of the challenges you might face is deciding what to do with the tagged values after running the deployment plan.

Should all the content items then be updated to have a new status of deployed, or ?

[MikeKry]

@deanmarcussen

Great to hear about possibility to use Placements to update summary view, did not know about this option.

I have created today for our project this custom deployment step based on taxonomies and I expect it to be tested a lot during next weeks. so if it will be okay, I can include it in OC then.

About changing / not changing status - I will check how it will work and how others want it to behave and then we can discuss this more. I think, that it will be enough without automatic transitions, but I would kinda like a possibility to do automatic transition, but maybe it could be part of workflow, because there are at least two possible scenarios: 1) stage environment contains a lot of content items and we want to deploy the same subset of content items every time - so we want taxonomy to stay on something like "deploy to prod" 2) stage is exact "copy" of production, we make some new changes on stage and want to deploy only the new items and check if everything was correctly deployed - in this case it would be good to make state transition, but this would be problematic, because long deploys fail on timeout (but are still processed by target server)

[deanmarcussen]

Cool, your other option, which would keep the deployment data away from the content item- where it probably doesn’t belong - would be to put an index on the deployment plan and index the items in the ContentStep with the version id and plan name. Then query this from a ContentsDriver when rendering SummaryAdmin.

Then when deleting the plan after publishing the indexes would be automatically deleted, and the content item is not polluted by deployment related data (which really it probably shouldn’t - the taxonomy would be by default rendered and the front end, for example)

[MikeKry]

@deanmarcussen

What do you think about extending taxonomy settings with new field "display in content item list", which would add taxonomy to adminsummary?

I have used view and placement like you suggested before and it looks like this now:

There are two options for general solution: a) leave display individual (everyone would implement placements etc. by themselves) - might be prefered option, but it would need to create an differentiator for each page type and field, or custom logic in view b) implement display into OC e.g. modifiing taxonomy.

[MikeKry]

We have tested this export step a lot and it works okay, but we did not add any selectors, settings are manual as you see on image below:

If it gives sense, I can merge it, or when I have more time, I woulda dd there taxonomy selector