'Start Workflow' Workaround

jklingman's Avatar

jklingman

16 Aug, 2010 08:28 PM

Since the 'Start Workflow' checkbox has been checked by default, I've had some upset developers here (including myself), and several upset clients as well, one of which refuses to let us upgrade her system to 6.7 until "this has been fixed". So I was trying to read up on it in order to formulate a solution. Joel's post here gave me hope that there is a workaround, but I've tried it and it doesn't work. I've done the following:

  • Removed all applicable groups from the workflow
  • Set the folder to NOT require workflow
  • Added the user to a group that does not belong to the workflow (which is overkill because of the 1st bullet above)
  • Ensured that the user's role has "Bypass workflow" enabled

Can someone tell me what I'm doing wrong, and what the end result should be? This is in our Test instance of 6.7.1, FYI. Thanks.

  1. 1 Posted by Bradley Wagner on 16 Aug, 2010 09:16 PM

    Bradley Wagner's Avatar

    Make sure the developers in question have the following ability disabled for their Site role:
    Be assigned to and use Workflow Definitions even if user does not belong to any of their applicable groups

    otherwise they'll be able to and encouraged to use any available Workflow regardless of group settings.

  2. 2 Posted by Klingman, Justi... on 16 Aug, 2010 09:22 PM

    Klingman, Justin's Avatar

    Bradley,

    I do that have that option disabled (unchecked) in the Role, but the client's site that I'm trying is not a Site (it's still a Target). Does it need to be in a Site Role for this to work?

  3. 3 Posted by Bradley Wagner on 16 Aug, 2010 09:27 PM

    Bradley Wagner's Avatar

    No you should be able to specify in a Global Role and have it work in the Global area.

    After verifying that, try adding a single group to the Workflow Def and re-testing. There was a legacy issue (might still be around) where having no applicable groups was equivalent to applicable for ALL groups.

  4. Support Staff 4 Posted by Tim on 25 Aug, 2010 03:31 PM

    Tim's Avatar

    Hi Justin,

    Any updates on this issue? Let us know if you are still having problems.

    Thanks

  5. 5 Posted by Klingman, Justi... on 27 Aug, 2010 02:00 AM

    Klingman, Justin's Avatar

    Tim,

    I haven't had a whole lot of time to play with this after Bradley's last post, but I'm not sure if I got it to work or not. I got it to not require a workflow, but then the Start Workflow checkbox wasn't available. Bottom line: I couldn't get the "Start Workflow" checkbox to be available, but NOT be checked by default, which is the goal. I'm still not sure if I got a clear answer on whether this could even be achieved or not. If not, then me trying is not worth it. Thanks.

  6. 6 Posted by Bradley Wagner on 27 Aug, 2010 02:46 PM

    Bradley Wagner's Avatar

    As per our blog post, if workflow is available to the user, it will be checked by default.

    The applicable groups options will make the workflow not show up at all for the users who aren't in the applicable groups.

    Can you describe the use case where you would sometimes want to use this workflow?

  7. 7 Posted by Klingman, Justi... on 27 Aug, 2010 05:40 PM

    Klingman, Justin's Avatar

    Bradley,

    The way I have always trained users of workflows is that they can make as many edits to a page as they need to, saving it, seeing what it looks like, etc. When they're 100% done with their edits, THEN they check "Start Workflow" in order to send it off for approval. In my mind, yes, a workflow is required for them to get their changes published, but why should they only be able to edit the page once before being forced into the workflow screen? In other words, the user could take several weeks to build a page and just save it without having to submit it into a workflow, simply because they aren't ready to finalize it yet. We use roles to control who can and can't publish, so if the user doesn't submit their changes into a workflow, they can't get them published.

    Now, I will say that I've realized in the past few days that maybe my thinking is old-fashioned (remember how long we've had Cascade). Before Save as Draft became available, my line of thinking made sense. But I understand now that they could Save as Draft, which won't kick them into the workflow.

    However, this is all for Contributors. I believe that Administrators who have permission to bypass the workflow in the first place should not be forced into the workflow screen at all, and that we (as administrators) should be able to set who the checkbox is automatically checked for. For example, if we do work for a site that has workflow, my developers should be able to bypass the workflow (without having to uncheck that box every time) since we're not here to participate in a workflow.

    I have a few customers who are upset by this change, because of what I just wrote in the previous paragraph. They believe, as Administrators, they should have the option to not have the Start Workflow box checked by default because they never participate in the workflow. One of those customers even refuses to upgrade from 6.2 until this is "fixed".

    In summary, I agree with Hannon Hill's thinking: "If a workflow is available, it should be used". Absolutely true. But in my mind, there are plenty of times where a user (Manager, Administrator, whatever) won't (and shouldn't have to) use the workflow. I think we just need more flexibility as Administrators to determine whether a workflow should be forced upon a user (checked by default) or not. Of course, Unchecking a box is easy, but it's just an annoyance that I think we can live without.

    With all of that being said, I'd be curious to know if any other users out there are unhappy with this change or not. If we're in the minority, so be it. Maybe I need to change my training philosophy. This turned out to be longer than I anticipated, so my apologies.

  8. 8 Posted by Bradley Wagner on 27 Aug, 2010 06:36 PM

    Bradley Wagner's Avatar

    Justin,

    Thanks for the thoughtful response. A couple of thoughts:

    1. The "save as draft" workflow you described is probably preferable to the frequent submits without Workflow. It will help avoid long, essentially meaningless version chains in the asset's version history.
    2. For developers that should be able to edit but should not use the site's workflow, I would recommend the Applicable Groups setting to hide the Workflow from them completely.
    3. I do understand that people want to be able to make workflow essentially optional for their users in more of "opt-in" kind of way rather than having to "opt-out". Attached is the Workflow Selection interface when more than 1 workflow is available. How would you like this as an option with only 1 workflow available? Obviously, as a user who could not bypass the workflow would not have the "None" option.

    I'm still a strong believer in reminding people of the workflows available on a Site (there's a reason they're there) but at least this way they can skip it without have to: click Back, uncheck the box, re-submit.

    What do you think?

  9. 9 Posted by jklingman on 30 Aug, 2010 01:31 PM

    jklingman's Avatar
    1. Agree.
    2. I will try that.
    3. I can give this a try (or are you saying that this needs to be built?). You're right...at least this way it takes out the headache of click Back, uncheck the box, re-submit. Is this something I can implement immediately?
  10. 10 Posted by Bradley Wagner on 30 Aug, 2010 01:38 PM

    Bradley Wagner's Avatar

    Justin, #3 is available when there is more than 1 workflow available to the user, but not when there is just a single workflow as is often the case.

  11. 11 Posted by Klingman, Justi... on 30 Aug, 2010 01:43 PM

    Klingman, Justin's Avatar

    Oh, I see. I probably should have known that, but out of all of the workflows we've done, nobody has had more than one assigned to a folder. Thanks!

  12. 12 Posted by Klingman, Justi... on 30 Aug, 2010 06:34 PM

    Klingman, Justin's Avatar

    Bradley,

    I assume that this solution won't work for us since we don't have two workflows. In other words, I'd have to throw another workflow on a folder in order to get the "None" option to show, correct?

  13. 13 Posted by Bradley Wagner on 30 Aug, 2010 06:43 PM

    Bradley Wagner's Avatar

    Yes, that's correct Justin. I should have clarified: my idea was that we include the functionality present with multiple workflows for cases with just 1 workflow in a future release of the software.

    For now, your best bet would be to use a dummy workflow for the second workflow, use the applicable groups setting so that only groups that should be using workflow have access to them, or train the users and the need to deselect the workflow before submitting.

    I updated the idea on the idea exchange that discusses this too.

  14. 14 Posted by Nate Tanner on 07 Sep, 2010 07:53 PM

    Nate Tanner's Avatar

    Number two does not work for me. I have administrative rights and I have made sure I am not a member of any of the applicable groups under the work flow yet it continues to have the start workflow checked by default when I make any updates.

  15. 15 Posted by Nate Tanner on 07 Sep, 2010 08:03 PM

    Nate Tanner's Avatar

    I just realized the administrator role is a built in system role that has
    "Be assigned to and use Workflow Definitions even if user does not belong to any of their applicable groups" checked by default.

  16. 16 Posted by gotankersley on 21 Oct, 2010 02:20 PM

    gotankersley's Avatar

    I firmly believe that there should be a global option where the 'start workflow' option can be disabled. In general this frustrates users (especially admins who rarely if ever are going to want a workflow) and in our case having the 'start workflows' checked by default is not a viable option because we have users who are in the same groups who have different levels of access.

    Here is a work around to disable the settings: In the /tomcat/webapps/ROOT/javascript folder there is a file called onload.js - this file contains code that is executed when a page is run. Open this file and paste the following code somewhere in the loadScreen() function

    //Uncheck default start workflow option
    if  (window.location.pathname.match(/^\/entity\/(delete|edit|move|copy)\.act$/i)) 
    {       
        var workflowCheckbox = document.getElementById('doWorkflow');
        var workflowOn = document.getElementById('doWorkflowStateChange');
        if (workflowCheckbox && workflowOn)
        {
            workflowCheckbox.checked = false;
            workflowOn.value = 'off';
        }
    }

    Then restart the tomcat for the change to take effect

  17. 17 Posted by amcmilli on 10 Nov, 2010 05:03 PM

    amcmilli's Avatar

    We are testing 6.7.3 and I tried that and it did not work. Did it work for anyone?

  18. 18 Posted by jklingman on 10 Nov, 2010 06:33 PM

    jklingman's Avatar

    amcmilli,

    I tried this on our 6.7.3 instance, and it worked perfectly. The trick is that you need to make sure the above code is INSIDE of the "loadScreen()" function (just before the closing '}' for that function). Also, you may need to restart. Note that each time you do an upgrade, I believe this file gets overwritten, so you'll need to re-install this code after each upgrade. Hope this helps.

  19. 19 Posted by amcmilli on 10 Nov, 2010 07:52 PM

    amcmilli's Avatar

    It did. Thanks! Now the work around is working.

  20. Tim closed this discussion on 16 Nov, 2010 03:10 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac