Info out of the starshot initiative webinar today: This is not possible. We'd need to provide a separate recipe to do it, recipes cannot be shipped as part of modules.
ultrabob → made their first commit to this issue’s fork.
Workflow Buttons now passes all linting and code analysis with no warnings or errors. There is another issue for adding tests, given that the existing tests were not testing Workflow Buttons features.
ultrabob → created an issue.
The drush recipe generator has never actually worked for me. Is it just me, or should we remove that link?
In the issue description, it says that "site feature" is commonly used, but the wordpress.com example is using "your site's features." These are just English words used together in a sentence, not a unit that is commonly used. I'm not sure what the benefit of prepending "site" to "feature" is, unless this issue is a proposal for core or Drupal CMS recipes only, which is not clear from the description. Feature seems a better alternative than site feature.
I'm likely missing some context that isn't in the description, but it seems to me, that just like modules and themes, recipes will need short descriptions for both their page on drupal.org, and eventually for project browser. I'm not sure that mandating a name is all that useful or enforceable.
I think it is hard for the name to provide enough information about the type of things done in the recipe, the intention of the recipe, and the scope of the recipe. I feel like it would be better to focus on better descriptions, and consider some type of mechanism for automating a summary of the actions a recipe will take in a way that it can be more easily absorbed than by reading the yml file, etc.
Something along the lines of headings like:
Modules Installed
Config Modified
Actions Invoked
Content Added
with summaries in them. We wouldn't want to dig into deep detail, but could give a summary that should along with a short description, give a good idea that the recipe does what you think it does.
In the issue description, it says that "site feature" is commonly used, but the wordpress.com example is using "your site's features." These are just English words used together in a sentence, not a unit that is commonly used. I'm not sure what the benefit of prepending "site" to "feature" is, unless this issue is a proposal for core or Drupal CMS recipes only, which is not clear from the description. Feature seems a better alternative than site feature.
I'm likely missing some context that isn't in the description, but it seems to me, that just like modules and themes, recipes will need short descriptions for both their page on drupal.org, and eventually for project browser. I'm not sure that mandating a name is all that useful or enforceable.
I think it is hard for the name to provide enough information about the type of things done in the recipe, the intention of the recipe, and the scope of the recipe. I feel like it would be better to focus on better descriptions, and consider some type of mechanism for automating a summary of the actions a recipe will take in a way that it can be more easily absorbed than by reading the yml file, etc.
Something along the lines of headings like:
Modules Installed
Config Modified
Actions Invoked
Content Added
with summaries in them. We wouldn't want to dig into deep detail, but could give a summary that should along with a short description, give a good idea that the recipe does what you think it does.
tekNorah → credited ultrabob → .
@wylbur thanks a lot for your work on this. It looks like at this point we only have three minor phpstan warnings left, which we could add to the baseline and try to fix later, but given that they don't look like hard issues, I think I want to fix them so we can start with fully passing gitlab-ci.
Thanks for the review wylbur! I started trying to fix the tests, and when I looked into them deeper, it appeared to me that the tests had been copied from elsewhere, and were not testing the functionality of this module. We need a follow-up issue to add some test coverage for the module.
ultrabob → created an issue.
I fixed some cspell issues and some of the test issues, but ran out of time to solve the menu_link dependency fail. It probably needs a composer.json added so that menu_link will be available to the tests to get the unit tests to progress further
ultrabob → made their first commit to this issue’s fork.
ultrabob → made their first commit to this issue’s fork.
The BOF schedule description for the coffee exchange says "be sure to register below" which may be leftover from something else, or maybe I'm missing a link somewhere? It may not be possible to change, but I thought I'd point it out, and this seems like the best venue for that.
This is related to the Testing Techniques page linked in Related Pages. It confused me to click on the Testing Techniques page and end up in the DeGov distribution documentation. I recommend that we either make it clearer, that that is where the link is going or come up with a version of that page for Drupal core.
It confused me to click on the Testing Techniques page and end up in the DeGov distribution documentation. I recommend that we either make it clearer, that that is where the link is going or come up with a version of that page for Drupal core.
Thanks for doing that. The checkers that come with GitLab-CI surfaced a bug that I've also fixed, and merged.
ultrabob → made their first commit to this issue’s fork.
ultrabob → created an issue.
It turned out that a cache clear was needed before trying to install. I'm still not able to install the recipe, but that seems likely to be related to the directory structure causing issues with the composer unpack plugin.
I've tried moving the kalastarter directory directly into the recipes directory with the same result, so it appears not to be a matter of where the recipe gets placed.
ultrabob → created an issue.
Kristen Pol → credited ultrabob → .
While this patch was completely ignored. It does look like someone came along and added a warning when there are no constraints, so I think this is good to stay closed. Thank you
hestenet → credited ultrabob → .
hestenet → credited ultrabob → .
hestenet → credited ultrabob → .
I've made several changes from fixing spelling errors to refactoring the javascript. It now passes all the CI checks. I just need a maintainer that is using it on their project to test that it still works as expected.
Code makes sense and the previously failing pipeline now passes! Thanks!
fjgarlin → credited ultrabob → .
Amazing, thank you for that quick fix!
ultrabob → created an issue.
Menu Link Weight 2.x completely changes the way it handles menu link weights. It begins doing it as a field, rather than using menu_ui. It would be welcome to make it work, but will also be a non-trivial undertaking. I'm going to adjust the composer.json file back to enforcing version 1 until this is complete.
Confirm I am running into this, just trying to get gitlab-ci configured for my module including next major version. My module doesn't have a package.json, so the failure seems unrelated to the module itself.
I've added RobLoach as a maintainer.
This does not work as expected in Open Social 12.
The group is translated:
In English it shows up properly:
In French interface it still shows in English:
Here is a modified patch to make it work again.
volkswagenchick → credited ultrabob → .
volkswagenchick → credited ultrabob → .
I'm hoping to work on it here today. If anybody pitches in I'll be thrilled.
I propose we build a form for this rather than trying to remove appropriate elements from the edit form.
ultrabob → created an issue.
Indrapatil, mlncn is this one good to close?
Thanks Katy,
Without investigating yet, I think that makes sense. The code that removes the fields that shouldn’t be there doesn’t impact the structure of the form where fieldsets are handled.
I’ll try to follow a new issue for that tomorrow and see if I can get it fixed.
Actually, it sounds like my problem is different. I'm trying to figure out why I can't access revisions, and this ticket is trying to restrict access to revisions further. Please disregard.
I installed the latest patch, and went in and turned on view all revisions in global permissions and the view revision permission under the group type permissions. I have tracked down where I get access forbidden down to Drupal\group\Plugin\GroupContentAccessControlHandler::entityAccess where the system is looking for a permission called "view all group_node:topic revision" against the list of permissions for the group in Drupal\group\Access\GroupPermissionChecker::hasPermissionInGroup. None of the permissions for the group had anything to do with revisions.
ultrabob → created an issue.
I can't figure out how to push to git in a way that is pushing just my changes to documentation. Every time I try to create a merge request, I end up with a mess, so I'll just upload the patch. I know there is an effort to rebuild the core install profiles in recipes, so I'm not sure what the actual pre-install requirements for recipes are, so I didn't go into much detail here.
I've installed minimal, at which point I could proceed with installing the recipe. I'll work on a modification to reflect that info, and add a ddev command for running drupal scripts.
ultrabob → created an issue.
I'm sorry for the spam while trying to fix the test. All the coding standards issues are fixed and I confirm that the patch fixes the issue we faced, but I don't have any more time to try and fix the test. Tests are not my strong suit. If someone else can make that work it will be great. I reverted to the original test code with coding standards fixes applied. I'm also attaching the new patch.
I confirmed that this issue still exists in version 4.0.x of the module, confirmed that the fix submitted previously in a patch still works, and created a merge request with the changes applied to the new version. I'm attaching the patch equivalent of that MR.
ultrabob → made their first commit to this issue’s fork.
Thanks for the follow. I'll install it, and have a look next time I can devote time to module maintenance.
I'm guessing that this meta section of the form may have disappeared when we introduced the feature to show buttons at the top and bottom of the form. I think we should probably loop through $form['actions'], $form['actions_top']. and $form['actions_bottom'] and add a corresponding meta section right before each if they exist and show current state is checked.
@ragnarkurm It would be really good to know what the value of
$transition_data
in cases where that code path is triggered, maybe there is a way to make sure we never get that far without the data we need.
I'd request three things from you if it is possible:
- The value of $transition_data when you reach that watchdog log
- What your workflow configuration looks like for the entity type in question
- If there are any particular actions you take that make the difference between having the error and not having it (i.e. it only happens when newly creating content, or it only happens on a specific transition)
@cxc891. Do you have anything to report back on this?
I think if the documentation in the related ticket I just added is good enough, this will can be closed in favor of the relate Meta ticket.
Without having tested this module, here is some potential documentation on how to use it.
After enabling this module, you'll have to apply it to one of more entity types for it to take effect.
From the admin menu, visit Configuration > Workflow > Workflows and then click "Edit" next to "Publishing (with draft and soft delete)"
Scroll down to the "This workflow applies to:" section and click "Select" next to the type of entity you want to use this workflow for, and check the checkbox for the entity bundles you want to use this workflow. Repeat as necessary and scroll to the bottom of the page and click "Save" to apply your changes.
For example, if you wanted to apply this workflow to the Basic Page content type:
- Navigate to the workflow edit page as described above.
- Click Select next to Content Types.
- In the modal that appears, click Select next to Basic Page, and Click Save.
- Scroll to the bottom of the page and click Save again.
- Optionally navigate to Admin > Structure > Content Types > Basic Page > Manage Form Display, and change the Moderation State field to use Workflow Buttons.
- Now when creating or editing a Basic Page, you should see the Moderation State selector in whatever form you have it configured.
If this seems ok/accurate, we can either add a help page, a README, or both for the submodule.
I see the description has been updated. Thank you, I think that does enough to clear this issue up.
Since it has been merged and other fixes built on it, I think it is good to go at least RTBC.
I've used this extensively first on nodes and later on other custom entities, for workflows where we need certain people to just review the content, and are not expected to make any changes to it. I control what buttons are displayed with transition permissions, but like you so, I usually hide the same to same transition when on an entity view, rather than the edit form. I'll be talking about this module at DrupalCon should my session be accepted, so I do think this feature is already useful.
@anweshasinha you are exactly right. I misread the change request on that option, when my initial testing didn't work as I expected. I just went back to recheck, and confirmed that it works the way your patch has it, and doesn't work with the ','.
Sorry for the confusion.
@anweshasinha Thank you, that is really great. I think the permission filter on the route needs to read _permission: 'access administration pages,access taxonomy overview' instead of _permission: 'access administration pages+access taxonomy overview'.
I'm not sure this is the final solution for this issue, I would expect the Structure menu to be available, when submenus of it are available to the current user, so I wouldn't expect to have to both enable modifying taxonomies and enable accessing the taxonomy menu. Beyond that there are other aspects of the Structure menu, such as managing content types, etc. that also tie into the need for this menu item.
With that said, your patch with the small change mentioned, solves the issue I'm having. Thanks a lot!
workflow_buttons_preprocess_node in workflow_buttons.module is where isDefaultRevision gets set. There is another issue for removing that preprocess 🐛 Remove unused preprocess Needs work . It would be interesting to know if removing that preprocess hook would fix this issue.
We could update the install hook and add an update hook to set the module weight to be lower than the token module's if it is installed, but it would be better to figure out the cause. I couldn't immediately identify what would be happening as a result of submitting via workflow buttons as opposed to selecting the target state and saving.
I'm running out of time to look at this today, but it seems like the next step is identifying what is happening on a workflow_buttons submission that would undo the work that token does on save.
That is just in case it gives somebody else a jumping-off point for trying to identify the culprit.
@cxc891 did you identify something in particular that lead you to the module weight solution?
@mlncn I can't promise a ton of active maintainership time, but that is true for most of us. If you are still interested in my help, I'd be glad to help out.
ultrabob → created an issue.
@mlncn if you have a thought on the best approach, I'd be happy to take a crack at this.
A summary of the change being made:
When using moderation buttons on entity/node displays, the module works by loading in the entity/node form, and removing all unnecessary elements, leaving the workflow buttons as the only visible form elements. This patch prevents the removal of the hidden form elements that antibot and honeypot inject. An alternate approach might be to not remove any elements that are hidden.
I propose a maintainer make a call on what to do here, and get the ticket closed.
My proposal:
Change the first paragraph on the drupal.org module description from
Provides buttons for content moderation, with each button based on configured workflow transitions, instead of a select dropdown of states.
to
This module works with the core workflows module to provide buttons for content moderation. Each button is based on configured workflow transitions and replaces the default user experience of selecting from a dropdown of states before saving.
Marking as a duplicate since the fix is already on that other ticket. Thanks @david-urban!
I'm sorry to reopen this after it has been closed for 2 years, but I do think it is still relevant.
In my testing, the "Use the administration pages and help" permission also controls access to the configuration admin menu, whether the user has access to anything inside it or not. So if I want the user to be able to edit taxonomy terms through the admin menu, but not have a configuration menu showing all the sub-menus, but with no actual content. I can't do it because disabling "Use the administration pages and help" disabled the structure menu altogether, even while the user has permission to do things in it.
I have confirmed that the application is on a paid account at the basic level. The application does not appear in the list of connected apps on the account. Is there some further authorization needed to allow the app to act using the accounts credentials?
This one should be on a basic plan. I'll confirm with the client that they created it on the right account, but I'm pretty sure it is.
ultrabob → created an issue.
I think @mlncn is right, that the most important place for this to be clear would be the project page on Drupal.org, and maybe in the README. Changing the display name or the module name would be a lot more pain for those already familiar with the module, than any conceivable benefit for potential new users looking for workflow or workflows compatible modules.
Here is the patch in case anyone needs it to fix this issue before it is committed.
ultrabob → created an issue.
Actually, it is on the dev branch, so you could require the dev branch and see if the issue has been resolved.
@david-urban I believe the MR in https://www.drupal.org/project/workflow_buttons/issues/3386885 ✨ Show buttons on Custom Entity view pages (replacement for Moderation control pseudofield) Needs review also addresses this issue, by no longer filtering which routes we should remove the extra form fields for. Could you try applying this change, and see if that fixes the issue?
Would the correct patch for this module be to update workflow_buttons/src/Plugin/Field/FieldWidget/WorkflowButtonsWidget.php->processActions to set a default moderation state for preview if it exists, rather than doing a form alter?
@mlncn Sorry for the long delay in replying. I've been out sick and then recovering from that. I've needed this on two projects now, so let me lay out my use case.
We are building some kind of approval flow, for which some of the approvers don't need to edit anything, they just need to indicate whether it is good to move forward or not. We send notification mails (and also list pending items on a dashboard) to those users when the content is ready for their review, and want them to see the content in a view mode, not on an edit form. After reviewing it, clicking a button to move the content on to the next state is all we need from them. On occasion we may need to alter the action to pop up a modal and ask for some more detail, but for most transitions, clicking the button and not changing the content is all we want them to be able/encouraged to do.
Thank you for the offer of co-maintainership. I'm afraid I don't have much bandwidth for active maintainership right now. I was learning a lot about this area of Drupal while submitting the MR request too, so I'm far from an expert. Let me set up notifications for issues on this module, try my hand at helping out on the issue queue for a while, and if it seems like something I can meaningfully contribute to, I'll inquire with you about whether you'd still like another maintainer?
By the way, I also ran into the issue with display being on by default, probably because that is not in the latest beta. if it would be better for me to change that line in this MR too, I'm glad to do it/see it done.