deployment state, user interface enhancements

Basically user interface enhancement, when the published is changed to draft, the ajax drupalBehavior is triggered and warns the end user what the consequences of this action are by changing the colors and adding help text drawing their attention to the instructions making it very clear to what happens.

without this interface, initial feedback from our client is that they don't want any deployments to happen outside of batch deployment. I'm not sure that they understand the benefit of being able to unpublish something from the production site (in case it was an error in publishing, etc) . I think this would be easier to understand with the ptsimard solution.

One other thing, is there a way to disable the deployment of users when they change passwords? we may want to have different admin passwords on source and destination but this isn't possible if autodeploy is happening for users.

basically the ptsimart deployment interface solution might help us sell the default deployment configuration, maybe if it was easier to understand they'd buy in.

If someone wants to send me their custom code for this 'hint hint', I'll refactor it for the distro, or else just modify it for our use.

Our clients really prefer using the queue.

We've configured the variable shared_content_source_deployment_disabled TRUE

drush vset shared_content_source_deployment_disabled TRUE

this allows us to deploy using the Queue and nothing but the queue. I'm wondering if we need to adjust our shared_content boolean settings , but so far deployment seems ok, with exception of field collections.

In addition to the ptsimard solution, I propose some additional user interface enhancements:

/admin/content

CATEGORY     TITLE             TYPE     AUTHOR   PBLSHD
News           Test deploy     Basic     admin       YES

CONTUED header

LANG     UPDATED     DEPLOY     DEPLOYED
Eng       Dec16 14:00     yes             no

UPDATED date time format: CUSTOM Md G:i

NOW for the dashboard/deployment/deploy node view:

same as above, except add filter for deploy to destination, only show if YES

use trim to trim language to 3 characters
use trim to trim categories to 10 characters

rename headers so that this fits nicely.

I've done this, makes content editing much better.

On the deployment bean view, similar thing, should only show beans that are marked for deployment. (filter on those)
a column for DEPLOYED needs to be added there on bean view for deployment as well. admin/content/ bean one too should have that
this will prevent mistakes and also will improve usability.

See my previous comment, this can be done while we wait for ptsimard, I Have done this in my local setup, seems like good default behavior and improves usability imho

when I have a moment I'll submit the patch.

Here's the patch .

TODO: The binary format for Deploy and Deployed should be formated as a Yes/No instead of 1/0

so we'll have to add a views format handler for that as we did for changed field from unix time to human time.

and speaking of which: There is one regression with this patch, to do with the changed date format handler. We should fix that first before commit

see http://cgit.drupalcode.org/wetkit_deployment/commit/?id=1f4ff7c8c819dadd...

Followup:

1) tried to format boolean as yes-no but having issues, here's the code I added to wetkit_deployment_source_views_data_alter (but it doesn't work)

  $data['entity_bean']['field_shared_content'] = array(
    'title' => t('Deployed'),
    'help' => t('Just an on/off field.'),
    'field' => array(
      'handler' => 'views_handler_field_boolean',
      'click sortable' => TRUE,
      'type' => 'yes-no',
    ),
    'filter' => array(
      'handler' => 'views_handler_filter_boolean_operator',
      // Note that you can override the field-wide label: 
      'label' => t('Deployed'),
      // This setting is used by the boolean filter handler, as possible option. 
      'type' => 'yes-no',
    ),
    'sort' => array(
      'handler' => 'views_handler_sort',
    ),
  );

2) just a note: wetkit_deployment_source_views_data_alter does not need to return $data
because $data is passed in by reference.

I think the problem is related to the view formatter being 'Key' , maybe there is a special way to handle formatting 'Key' for boolean values , not sure why it'd be different.

sounds good.