When a user does not have rights to publish a page, he sees "Request publication" button in Touch UI editor mode. When he clicks on "Request Publication", the workflow "Request for activation" starts and go to the admin's inbox. I want the page to go to some other group for publishing. How can I achieve this?
As shown in the image above, you can change the user/group to be anyone/anything in your instance.
You just need to change properties of default "Request for Activation" workflow.
However, it is recommended to make a new workflow of your own so that upgrades and patches don't revert your changes.
On the /libs/cq/workflow/content/console.html page with all available workflows. You should find workflow that you are interested in.
In you case it is possibly http://localhost:4502/cf#/etc/workflow/models/request_for_activation.html
On this page you can workflow config which contains several steps. Open for editing Request for activation step, switch to tab Arguments and then you can change Name patterns field. It should be regex pattern e.g. .*approver.* for all groups which contains approver in name.
As a variant you can custom workflow or step. In this case you need to figure out by you self how to configure it but usually it is something similar.
Related
Objective
We would like to setup multi-site wagtail with approval chain.
Develop -> QA -> Release -> Production
Description
A develop / content editor goes to the wagtail admin and creates the content. Once done, sends the request for approval to move to QA site.
QA moderator reviews the content on develop site. If approved, the content gets moved to QA site. The content carries over to next stage approval (release).
Same process ahead for next sites in approval chain.
Questions
Is it possible to setup a publish chain with approval policy in wagtail? I tried to research a bit but could only find "workflow" and "workflow tasks". Do I need to custom code a workflow task to be able to achieve this?
This should be possible but you will need to consider what you really want to do in regards to the 'move' step, do you want to actually move the Page instance to a new site in a new tree or copy the current (and its history) and move that copy Page OR make a copy to put in place of the Page that was moved.
Nonetheless, the documentation on how to add a new Task type is the best place to start, it walks you through custom Task types.
In the solution below however, I thought it would be simplest to create a new model that behaves exactly like GroupApprovalTask (the default task included, used for moderation) but add a field that links it to the Site model.
This way, in the admin UI the admin users can now create as many PublishSiteTask as you want, one for each Site (QA/Dev/Prod etc) and then each of those could be linked to different user groups. It is important to differentiate between the database model (a task type with some fields) and the instances (a task created in the UI) and the actual task instances that are created against each page revision (not page) as the workflow steps progress.
Code Example
models.py
from django.db import models, transaction
from wagtail.core.models import GroupApprovalTask, Page, Site
# ... other imports
class PublishSiteTask(GroupApprovalTask):
site = models.OneToOneField(Site, on_delete=models.CASCADE)
admin_form_fields = ['site'] + GroupApprovalTask.admin_form_fields
#transaction.atomic
def on_action(self, task_state, user, action_name, **kwargs):
"""Performs an action on a task state determined by the ``action_name`` string passed"""
if action_name == 'approve':
# get the page that this action is referring to via the task_state.page_revision
page = task_state.page_revision.as_page_object()
# find the new parent target at this task's site
# how this is done depends on the site/page structure
new_parent_target = self.site.root_page
# move the page to a new location
# note: this will actually move it from its current tree, you may want to make a copy first
page.move(new_parent_target)
# be sure to preserve any existing task behaviour
super().on_action(task_state, user, action_name, **kwargs)
Additional Links
Task class definition
GroupApprovalTask class definition
You may want to do some pre-work in the code to check that the page can actually move to the different Site, each Page has a method can_move_to that could help.
The move method referenced above is part of the Wagtail code but the full docs for that method can be found in the Treebeard API docs which Wagtail uses to manage the tree structure.
In Keycloak, by default, users are able to change their first and last name in the account manager page. However, is it possible to disable this behavior?
Removing both fields in the theme results in those values not being sent and the form failing, and a hand-crafted POST request would defeat this method anyway.
I came across a similar problem and after reading this SO post, came to know that although you can disable/hide fields in ftl, you cannot disable form validation
For e.g I hid firstname field , but still cannot submit. Same was the result with disable as well:
I am not aware about disabling a particular field in some other way. However there is a workaround in which you can disable the entire account modification flow (Password can still be changed by Forgot Password option).
Bu default, account modification is enabled, but you can disable it for a particular realm by going to Realms -> Clients -> Account.
The result of this will be, the account page will be inaccessible:
You can remove the client role 'manage_account' for client 'account'.
In Keycloak, by default, users are able to change their first and last
name in the account manager page. Is it possible to disable this
behavior?
That can be done out-of-the-box (since Keycloak 14) by using the user profile functionality. First, the preview feature declarative-user-profile has to be enabled. For that start the server with:
--features=declarative-user-profile.
for the Quarkus version, or with
-Dkeycloak.profile.feature.declarative_user_profile=enabled
for the Wildfly version.
Bear in mind that:
Declarative User Profile is Technology Preview and is not fully
supported.
After starting the server with the aforementioned option, go to the Keycloak Admin Console and:
Go to the according Realm;
Go to the tab General;
Set User Profile enabled to ON
A new tab named User Profile (top right) will show up; click on it, and a set of configurable attributes will be shown.
Click on firstName, and then go to Permissions
In that section the permissions can be changed, accordingly. For example, if one sets Can user edit? to OFF, then when the user tries to change the firstName field in the account UI, that UI throws the following warning message:
The field First name is read only.
The same configuration can also be applied to the lastName attribute.
For the new Keycloak UI the workflow is exactly the same as the one I have just described. More information about the feature can be found in the official keycloak documentation (link)
You can use readonly property to disable email you can just change the following line:
<input type="text" class="form-control" id="email" name="email" readonly autofocus value="${(account.email!'')}"/>
This is for the Notification Plugin (link here) for Jenkins.
I have a bunch of Jenkins jobs that I want to keep an eye on. I want to be alerted/emailed when any changes are made to a job so the job notification plugin should be helpful. This plugin adds a subsection to each Jenkins job for us to configure. We have to check the checkbox and enter email addresses for each job to notify us whenever there's a change.
I want to define some environment variable that contains emails so I don't have to go into each job to add/delete email addresses for interested parties; that I can just add/delete addresses from this variable. Can someone tell me how to do this or am I out of luck and the field only takes email addresses and not variables containing email addresses.
Screenshots from my Jenkins:
Global variables defined in Jenkins:
Field in Jenkins job notification heading that doesn't allow me to enter a variable for emails:
This appears to be fixed in version 2.144 (both "${DEFAULT_RECIPIENTS}" and "$DEFAULT_RECIPIENTS" reference the global property fine in the "Recipients" field).
Otherwise, I use the Email Extension Plugin ("Email-ext") for much more flexibility.
Once installed, to configure the plugin, navigate to Jenkins -> Manage Jenkins -> Configure System, and scroll down to "Extended E-mail Notification".
There you can set the global defaults, such as "Default Recipients".
These settings are assigned to tokens, such as "$DEFAULT_RECIPIENTS".
Click the "?" button for each setting and note the token name.
Note the "cc:" and "bcc:" prefixes to put an address on "cc" or "bcc").
Then, in your job configuration (/job/myJobName/configure):
Go to "Post-build Actions"
Click "Add post-build action" and select "Editable Email Notification".
Ensure that "$DEFAULT_RECIPIENTS" is in the "Project Recipient List", with any other addresses (note the "cc:" prefix to put addresses on "cc").
Click on the "Advanced settings" (bottom left of the "Editable Email Notification" configuration) to show the "Triggers" section and configure emails depending on the build status, like "Always", "Failure", etc...). Click the "Advanced" button for each trigger to get more options.
Once this setup is done, you can edit the global "$DEFAULT_RECIPIENTS" to change the emailing for all jobs configured as above, and have the functionality you require.
PS: I know this is old, I hope my answer may help others - like me - that have the same question.
I've been trying to follow a similar approach as that of yours, with the only difference of having a job parameter being assigned the recipient's address.
I encountered a problem where the plugin wasn't able to parse the job/environment variable to it's assigned value (the email address).
For example,
emailID=xxxxxx#yyyyy.com
Now this particular variable was being sent into the emailing list as ${emailID} and not as xxxxxxx#yyyyyy.com
The fix? Really funny.
Your variable must be the first comma seperated value in the mailing list.
You can refer to the attached image below.
As you can see, just keep the variable first, and then your predefined values or the plugin's variables
We want to develop a smooth-flowing workflow experience (but still use workflows). Currently, a user needs to use the sidekick to initiate the workflow, then to the inbox, which takes them back to the page to use the sidekick again. When they go to the inbox, they need to restrict to the model and path of the page. It would be nice for the user to only have to go to the content page and from there, launch the different workflow forms that need to happen, like a little "inbox" right on the page that is subject to the workflow.
I have written a custom component that can initiate the custom workflow. The custom component can also query the WorkFlowSession and obtain any active WorkItems for the current page that the component resides (using the WorkItemFilter interface). What I want to do is provide a link to the user to the next step in the workflow from the custom component, just like the inbox does.
Here is an example output from an WorkItem instance toString method:
21.05.2014 09:45:29.300 *ERROR* [0:0:0:0:0:0:0:1%0 [1400679929160] GET /content/test/mailing1.html HTTP/1.1] org.rand.whatcounts.EmailCampaignCoordinator Found workitem: -----------------------------
WorkItem Id: /etc/workflow/instances/2014-05-21/model_1400679794564399000/workItems/node4_etc_workflow_instances_2014-05-21_model_1400679794564399000
Workflow Id: /etc/workflow/instances/2014-05-21/model_1400679794564399000
Payload: /content/test/mailing1
Payload Type: JCR_PATH
key = historyEntryPath value = /etc/workflow/instances/2014-05-21/model_1400679794564399000/history/1400679924113
key = comment value =
My hope is that by using the workflow api items, I can create the link that the user could click on to proceed in the workflow (just like the inbox).
Thanks for listening!
Phillip
There are two ways to implement this
Java-Based Solution
I was able to figure out one way by looking at
http://localhost:4502/libs/cq/workflow/components/inbox/list/json.jsp
The important part of this jsp is that, given a workItem instance, you can get the path for your next step using the JcrPathBuilderManager:
pathBuilder.getPath(wi);
Using this, I was able to output a link to the next step in the workflow to the user (without having user go to their inbox).
Javascript/JSON Based Solution
I didn't go far with this solution (I didn't write any js) but this was my fall back position if I didn't find the java-solution listed above. Once could implement custom JS in CQ Component that would call the json feed for the user inbox, do some client side filtering (to restrict it to only items related to current page). The URL to the feed is
http://localhost:4502/libs/cq/workflow/content/inbox/list.json?start=0&limit=40
Thanks!
I'm building a custom module in SugarCRM Community Edition, I have everything set up as i'd like (almost).
In my Module i have a checkbox marked 'Processed' what i'd like to achieve is that when this checkbox is marked, the users who are 'sales agents' and not 'admins' can no longer view this record.
They need to be able to have access to the record up until the point it's marked as processed. Is this possible?
Yes, look at /modules/Employees/views/view.list.php in listViewProcess() to see how the list view always filters out users based on the status value. You would do something similar for your module to filter out Processed. Then if you need to also ensure that they can't access the record directly make sure to take care of the edit/detail views as well. In both view.detail.php and view.edit.php (or in the module's controller) check for Processed being set and if so (and perhaps not an admin or some other user type) display a "This record is already processed" message and/or do a redirection.