Thanks Nathan.

I've moved onto other tasks on the project for the moment, but I'll hopefully look at it this week.

Regards,

Tim

Hi Nathan,

I've installed the updated version this morning and it's looking a bit better.

Take the following content tree:

Home

• Folder1
  • Page1
  • Page2
• Folder2

Default permissions are Browse Node, Create, Send to Publish etc. I have set granular permissions as Browse Node only on Folder1

When I log in as that user and select Folder1 I now only get a Preview button as expected (no Save, Publish etc). However when I select Page1, or Page2 I get Save, Request Publish and Request Unpublish.

Clicking Save on the child page gives me an "Authorization error", clicking either of the other two give an "OH SNAP!" error once I've filled in the comment and clicked save.

Additionally if I try to Save my workflow settings (with or without changing any settings) I get the following error (with nothing in the log as far as I can see).

Regards,

Tim

Hi Tim

Do you have any workflow configured for the site? Wondering if you might be getting the error on saving content as the package will be trying to initiate a workflow process but not finding any assigned groups?

Will look into both.

N

Hi Nathan,

I have no workflow for the document type of Folder1 or Page1 in my example above. I do have some workflow configured for other document types.

I get the same error as in my most recent screenshot above when I try to set an approval flow at the individual node level.

Tim

Hi Pradeep

From version 0.2.x onwards I'm supporting Umbraco 7.7 minimum. Not sure though that your issues would be caused by the Umbraco version - the 7.7 restriction was for the improved user management UI.

Will spin up a new 7.6.6 instance when I have time, and will get back to you.

Hi Pradeep,

Apologies for jumping in here - but I had this initially as well. You need to grant access to users to see the Worfklow tab in the side bar. So you have to go to the Users part, then navigate to the user group you're assigned to, then 'add' the Workflow section. It'll then appear.

It looks like you don't have the Users tab either, though, so you might need to ask whoever set up your user account to allow you access to it.

Once you can access the Workflow tab, you can then set up workflow approval - which will then appear in the 'Workflow approval flow' panel from your screenshot.

Hope that helps!

Thanks Nicola, that's likely it.

Might update the installer to automatically grant access to all site administrator users...

Sorry Nathan, I'm having different problems now.

I've tried an install over the top, and a fresh install of 0.2.0.078.

I can view the workflow dashboard section okay, but can't do much more than that.

Clicking on Approval Groups/My group gives a 404 (/App_Plugins/Workflow/backoffice/approval-groups/edit.html), adding a new group also gives a 404. Clicking on History or Settings takes me straight to the Content root.

The chart and documentation tabs are showing. I can set the workflow configuration on the content tree without issue.

Looking into the 404 problem, and at your project on GitHub I think there are a few views missing from the build, I do not have a folder App_Plugins\workflow\backoffice\approval-groups. It works okay when I manually add these files.

I can't identify the cause for not being able to view the workflow settings or history pages though.

Tim

That route shouldn't exist - the changes in a previous commit split those to /config/saveconfig and /config/savedoctypeconfig, for the node-based and doctype-based configs respectively.

Did you uninstall then reinstall, or just update files? Sounds like it could be some JS cached in the backoffice hanging onto the old routes. What do the saveConfig and saveDocTypeConfig functions in workflow.resource look like?

I'm having problems installing any package in that particular environment (similar to this: different grant set message). I've been installing the package over the top in a local environment, and then copying the app_plugins and dll across!

Refreshing the cache has sorted it.

Thanks,

Tim

No worries, glad you got it sorted

Appreciate your feedback too, helped to expose a few bugs and bits that I'd missed.

Hi Nathan,

I'm picking this up from Tim.

The button options presented to users once a page has been submitted to the workflow are the wrong way round, i.e. an admin user (with permission to publish) sees an option only to 'Cancel workflow' whereas a writer (without permission to publish) sees options to 'Approve changes', 'Reject changes' or 'Cancel workflow'.

These options are seen when a user either selects ‘Edit’ from the dashboard or just navigates to the page in question in the back office.

Admin (with permission to publish) sees:

whereas a writer (without permission to publish) sees:

The approval groups and workflow are configured correctly (Tim also checked) – just the button options seem to have been applied the wrong way round. Tim thinks this wasn’t a problem in the last release. (And just to clarify, the button options before a page is submitted to the workflow are correct - it's just afterwards that they're not).

Is this something you'd be able to fix for us?

Thanks!

Nicola.

Hi Nicola

I've just released a new build, should resolve the button issues. It's available here - https://ci.appveyor.com/project/nathanwoulfe/umbracoworkflow/build/artifacts

Change -

    vm.buttonGroup = {
      defaultButton: vm.canAction ? buttons.approveButton : vm.adminUser ? buttons.cancelButton : null,
      subButtons: vm.canAction ? [buttons.rejectButton, buttons.cancelButton] : []
  };

Change means a user with permission to action an active workflow will have the approve button, with reject and and cancel as the sub-buttons, and any admin user (admin in this context is a user with access to the workflow section) will have a cancel button only, if the current node is in a workflow.

Keep in mind that the permissions for the workflow are completely separate from Umbraco's roles/permissions - any member of the final group in a workflow will be able to publish changes to the live site.

Hi Nathan,

Thanks for getting back to me so quickly.

In our setup, we've only allowed editors and writers to see the content and media sections of the sidebar - so they wouldn't see the workflow section there. Is that what you mean by "access to the workflow section"?

Apologies for all the daft questions but I'm not a developer :)

I'll pass this on the team so we can try it out - thank you!

Nicola.

Yup, exactly that - if the workflow if nnis in the sidebar, they'll be treated as a workflow admin, which means they can cancel any current workflow.

Permissions-wise, any user in the final group of a workflow will be able to publish, regardless of their actual user permissions. By being part of the workflow group, their permissions are elevated so that they can administer the workflow.

We never want writers to be able to approve changes and publish the page, though - so if they're not in an approval group, they won't have their permissions elevated, will they? (sorry if I've misunderstood - I'm sure it'll make more sense once I'm using it!).

That makes sense - you'd have editors in the workflow groups, writers would just be business as usual, with their changes being sent for approval, which initiates the workflow.

Will be clearer once you start playing with it.

Great - thank you! And yes, I'm sure it will - it was all looking great in the last release, and ticking off lots of boxes from my backlog :) Thanks again!

Hi again Nathan (happy new year!)

Our Content team (stakeholders) have been trying out Plumber. They're much happier with the buttons having been switched round, so thanks very much for having sorted that!

I've got a couple of questions, though, from their testing.

1. If a user submits a page to the workflow using the 'Request publish' button but without having first saved the page, the edits they've made are not saved and carried through. In other words, when the Admin user then goes to preview the page before approving it, they see the page in its last published state without the edits. This means they're not able to approve what they're meant to be trying to approve.

Is this expected? Or can the 'Request publish' button incorporate a save?

2. If a user goes to a page that's currently in workflow, they can add extra edits to that page. If they navigate away again, those changes can be discarded. If they stay on the page and preview, however, those changes are saved. When an approver then looks at that page as part of the approval stage of the workflow process, they don't only see the original edits (the ones submitted to the workflow) but they also see the subsequent extra edits.

Is it possible to "lock" a page, so that if it's already in a workflow no subsequent changes to it are saved? (Or, if they are saved, the page has to go through the workflow again for them to take effect?). An editor might think they've submitted certain content for approval, while an Admin actually sees completely different content.

Thanks very much!

Nicola.

Hi Nicola

I'd written a lengthy, well-rounded response (at least, I thought it was), then tapped the back button in my phone and lost it...

Short of it was I can certainly improve both those cases.

User feedback trumps testing any day, so thank you.

Hi Nicola

Just updated the package, should resolve both these issues.

1 - if changes have been made to a page, the request publish button is replaced by save. request publish is only displayed when the page is unmodified or freshly saved 2 - only users in the current workflow approval group are shown the action buttons, all other users only see the preview button, which no longer performs a save on content already in a workflow

Latest version is here - https://ci.appveyor.com/project/nathanwoulfe/umbracoworkflow/build/artifacts

Hi Nathan,

Wow, that was fast! Brilliant - thank you! I'll get this update installed in our next sprint and let you know if we have any more feedback!

Thank you!

Nicola.

No worries at all - great to get feedback for actual use cases rather than me just trying to think of scenarios!

Keep it coming!

Hi Nicola

I'll need to double check on the current version, but pretty sure this has been resolved...

N

Great - thank you! (Sorry - I found your version history after I started posting, but as I'm not a developer I didn't want to risk misunderstanding what was listed!)

Hi Nathan,

We are looking to purchase license for Plumber in Umbraco 8. Is there any trial license to test the functionality in one of our dev or test regions. Could you please assist ?

Thanks,

Anil Kumar

Hi Anil, to use a test license, create an empty file named test.licand drop it in /app_plugins/plumber. Restart the site, and you should have access to all licensed features on local/dev environments.

N

Hi Anil

I think this will be fixed by using an impersonation license on your local environment (drop test.lic into app_plugins/plumber, file can be empty).

However, there were some other issues in 1.6.2 related to email notifications not sending. These are fixed (I believe) in the 1.6.3 beta which is on nuget now. The only changes in the beta are to fix these bugs, so despite only being a beta, it's perfectly ok to use - will have a proper release this week.

cheers Nathan

Hi Nathan,

We have upgraded plumber to 1.6.4 . I do not see the old issues after the upgrade but I see the license is still not detected even after adding the .lic file in the App_Plugins\plumber . Please assist

Thanks,

Anil Kumar

Hi Anil

Looking at the screenshot, I'd say the keyfile is missing - in /app_plugins/plumber, there must be plumber.lic and plumber.key. Both files need to be deployed on the licensed server.

I've added the public key to the repository at https://github.com/nathanwoulfe/Plumber-2/tree/master, save this into /app_plugins/plumber and you should be back in business.

Hi Nathan,

Thank you so much. It worked finally. I am excited to test the complete functionality of the plugin. I appreciate it.

Thanks,

Anil Kumar

Glad to hear it's working. If you have any issue, feel free to raise them on the issue tracker at https://github.com/nathanwoulfe/Plumber-2/issues

Hi Nathan,

We are experiencing a strange issue while using the Plumber Workflow package 2.0.2. Users are experiencing the following issue in the Request Publish page . It keeps on spinning and never ends when we hits the button to Request Publish Button. This is happening to a specific Umbraco node in the content. Could you please assist.

@Nathan Woulfe

We have updated the Plumber workflow to 2.1.9. All the users are experiencing the infinite spinning of the Request Publish button. Could you please assist?