New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] Ability to hide workflow transitions in backend #3616

Open
gadget60 opened this Issue Nov 16, 2018 · 13 comments

Comments

Projects
None yet
4 participants
@gadget60
Contributor

gadget60 commented Nov 16, 2018

Feature request

For workflow PLACES there exists a parameter "visibleInHeader". I wish to have an equal setting for workflow TRANSITIONS: A setting that just hides a transition from being displayed in the workflow actions menu.

Background: We have set up a workflow that is partionally automated, meaning some transitions will be started by imports via maintenance cron.

image
To get an image:
Imported products both require manual interaction (assigning assets - lower part in the workflow above) as well as augumenting data from a second source (upper part in the workflow above) in order to be published. I therefore would like to hide the automated transitions in Pimcore backend.
To be clear: This is not a permission issue, setting up a guard just arises other problems. I just want the user to see the actions (transitions) that he actually is supposed to apply!

@dpfaffenbauer

This comment has been minimized.

Contributor

dpfaffenbauer commented Nov 16, 2018

do you require to display anything in Pimcore backend for this workflow? If not, just use symfony workflow directly.

@gadget60

This comment has been minimized.

Contributor

gadget60 commented Nov 16, 2018

Yes, I need to display some of the transitions... Thanks for your suggestion anyway.

@markus-moser

This comment has been minimized.

Contributor

markus-moser commented Nov 16, 2018

I've done this with guards. Why do guards not work in your case?

@markus-moser

This comment has been minimized.

Contributor

markus-moser commented Nov 16, 2018

But yes, might be a good idea to a flag for this.

@fashxp

This comment has been minimized.

Member

fashxp commented Nov 16, 2018

I would try to go for guards ... because it might prove useful at some point, that a admin user would still be able to trigger a certain transition manually ... because you never know ;-)

@gadget60

This comment has been minimized.

Contributor

gadget60 commented Nov 16, 2018

@markus-moser: Actually I did solve it using a guard, but what I came up with is pretty ugly. I require a certain role, something like:

        guard: "is_fully_authenticated() and has_role('ROLE_DATA_IMPORT')"

...whereby the user does not belong to the ROLE_DATA_IMPORT. So far, so good - transition is hidden.

Problem now is: At some point the transition MUST be applied during the import, launched either via console command (where no permission system is present at all) or manually in the backend GUI, launched by the same user that does not belong to ROLE_DATA_IMPORT. In both cases I must create/inject a fake token in order to not throw an exception. This is why I said it is not permission issue. The user actually has permission to launch the import, which in turn applies the transition.

You solved this using guards - maybe you enlighten me at this point....? :-)

@markus-moser

This comment has been minimized.

Contributor

markus-moser commented Nov 19, 2018

@gadget60 I had exactly the same situations. There are some different possibilities to solve it. I used a custom guard event subscriber instead of a guard expression. Then it's possible to disable the guard for the import process. Another way would be to check the subject attributes. For example if the importer sets an attribute "importedId" then it's possible to extend the expression with "or subject.importId != ''" or something like that.

@gadget60

This comment has been minimized.

Contributor

gadget60 commented Nov 20, 2018

@markus-moser Thanks, I see your point. Didn't think about your approach.
@fashxp I'm gonna close this issue then - still think it would be a nice feature but the suggested way works for me too.

@gadget60 gadget60 closed this Nov 20, 2018

@fashxp

This comment has been minimized.

Member

fashxp commented Nov 20, 2018

@gadget60 didn't try it, but shouldn't that work?
guard: "(is_fully_authenticated() and has_role('ROLE_DATA_IMPORT')) or (!is_fully_authenticated())"

@markus-moser

This comment has been minimized.

Contributor

markus-moser commented Nov 20, 2018

@fashxp should work for the importer but not if the user has the possibility to trigger the importer in the backend and the authenticated user applies to the import job too.

@gadget60

This comment has been minimized.

Contributor

gadget60 commented Nov 20, 2018

Nope - just gave it a try. It does not even work for the console command. As soon as I use any guard that checks for authentication I get an exception "There are no tokens available for workflow product_workflow."
Also see symfony/symfony#26401

@markus-moser

This comment has been minimized.

Contributor

markus-moser commented Nov 20, 2018

Maybe a good solution improvement for the future could be if we add a is_in_actions_button() helper function for the expressions.

@fashxp fashxp reopened this Nov 26, 2018

@fashxp

This comment has been minimized.

Member

fashxp commented Nov 26, 2018

ok let's reopen that and see if adding this helper is possible.
pull requests are welcome ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment