Comments

zhangtaihao’s picture

Added tag.

zhangtaihao’s picture

Issue summary: View changes

Describe the Rules issue.

zhangtaihao’s picture

Issue summary: View changes

Added task on exporting conditional elements.

zhangtaihao’s picture

Changed tag.

zhangtaihao’s picture

Issue summary: View changes

Added fluent interface issue.

zhangtaihao’s picture

Issue summary: View changes

Update pending issues.

mitchell’s picture

While trying to find a way to speed up #1666802: Keep embedded elements under compatible containers in container UI and related issues, I tried to figure out the most logical issue that encapsulates these upstream issues so that they be made into a sandbox fork / patch-set. It was a separate, long-term goal of mine to find a suitable path to incorporate Conditional Rules into Rules core, but I think that it is this feature that encapsulates the commit flow. So, I'd like to propose updates to the roadmap that I think will allow us to get the most benefit in the fastest possible way, especially in relation to the stalled upstream issues.

Gist of what I'm thinking:
* Move this issue to the Rules queue as a meta issue / initiative
* Re-title to ~"[Meta] merge conditional rules"
* Make a sandbox fork tied to this issue that merges the relevant issues and the If/Then/Else plugin
* Mark issues in #1666842: Cross-referencing Rules issues as duplicates of this one
* Send a pull request to klausi & fago for a rebase to either 2.x or 3.x
* Merge the While plugin as a patch in #1329904: Loops: while and tail recursion support and also solve fago's criteria: "if many folks come up and state their need for that + it comes with a decent UX, I'd be happy to include the feature."
* Create a new issue for Switch/Case and reference #326808-5: Support logic-based dialects (if/then/else)

Items to add to the roadmap
* Review available UI changes and simplifications discussed in relevant issues (ie. #1269884-2: Inline rules support)
* Documentation updates
* Write a change notice

@zhangtaihao: What do you think of this approach? I see you've already been successful with two other projects using the same workflow.

zhangtaihao’s picture

I think it'll definitely garner more support. The way I see it, #1666802: Keep embedded elements under compatible containers in container UI and a bunch of other issues stalled because they are either (1) not visible enough or (2) lack sufficient general expertise for in-depth review and testing. (Of course there's also the fact that fago has lately been running like wild on core issues.)

I will happily update issues on my end if it means stuff in this module will get more love from Rules folks. @mitchell: Would you be able to land some details with the other Rules maintainers regarding the "sandbox fork" or "2.x or 3.x" branch? I'd just like to know the specifics so that I can be sure of what direction I'm headed down (e.g. possibly co-maintain a "3.x" branch??).

Once we head down this road, I'd also like some guidance on documentation updates and change notices, though I think #1269884: Inline rules support is an additional feature altogether (i.e. inline rule) simply because I don't know if it's even possible to override tabledrag.js to have undraggable rows as children of draggable ones (i.e. rule condition set and action set).

mitchell’s picture

~> I think it'll definitely garner more support. [And, it will pick up when there is] either (1) [more] visibility or (2) [] sufficient general expertise for in-depth review and testing.
I agree! :) Even if it still takes some time to get in-depth code reviews, building a user base will be (1) awesome because this code rocks (2) a good step in the direction of fleshing out docs with the help of users who similarly report that it's #1689358: Just what rules needed!!. Having all the code in one place will also be a big time saver for experts.

> Would you be able to land some details with the other Rules maintainers regarding the "sandbox fork" or "2.x or 3.x" branch?
I'll work on it! :) ..This is just speculation, but after thinking about this some more, I'm fairly confident fago will favor keeping this in 2.x, because in the past, he has leaned heavily toward incremental changes over large milestone aims. I think since conditionals wouldn't break anything, this is a good reason to anticipate a merge in 2.x. Maybe bumping the releases to 2.5 may be called for, so I'll ask about that idea too.

> (possibly co-maintain a "3.x" branch??)
I think it would be incredibly beneficial if you also maintained Rules! I also think this sandbox fork is an advisable route toward directly indicating your attention to detail and familiarity with Rules code maintenance. Perhaps fago will invite you to merge the sandbox so that he can stay focused upstream and klausi can continue working on RestWS, the Project Application Review initiative, Entity API, etc, etc.

> I'd also like some guidance on documentation updates
I'm still working on the docs following #1092440: Recompile documentation for Rules; lately, I've mostly been trying to figure out suitable flows and organization schemes for all the content. I'd be happy to work on these docs, and would greatly appreciate the contributions of other users too, especially in this early development stage. I just created http://drupal.org/node/1698218 as starting point. (Note: most of that section's content is temporary placed until my next major overhaul, and I'd like to break up that page once it's more developed and the code is closer to merging.)

> and change notices
idk much about what we would do for this yet. If there's no underlying API change, then I'm not sure if it's necessary. Primarily, I think blogging about the major update from yours or fago's site and syndicating it to the Planet would be most beneficial.

>> Review available UI changes and simplifications discussed in relevant issues (ie. #1269884-2: Inline rules support)
> I think #1269884: Inline rules support is an additional feature altogether...
That was a really helpful description, and looking at your comment there and Rules Embedded more closely, I understand that issue a lot better. My main thought behind this was based on fago's remark, "Best, we'd hide the actions and conditions from the overview, such you have to click edit to be able to edit it (just as for rules sets). Then make the name optional, e.g. have it to default to "inline rule" or so." This lead me to [#12345: Remove Conditions from the Rule Component overview screen] in conjunction with #1670648: Make components the default configuration type.

@zhangtaihao: Thank you so much for your work! --bow--

zhangtaihao’s picture

I'm very glad you like my work!

I will keep this issue as literally a roadmap for merging into Rules, but some of the posts in this issue may be confusing in Rules. Thus, I have created #1698296: [Meta] Merge Conditional Rules.

This issue will be kept open until all outstanding items per #3 have been shifted to the other issue. Then, I will close this as a duplicate.

zhangtaihao’s picture

Issue summary: View changes

Moved fixed issue to optional list and moved other Rules issues from homepage.

wylbur’s picture

Issue summary: View changes

I know this is a very old ticket, but it would be great to release a new version with some updates for very basic updates like PHP compatibility issues.

Is this the right place to do this, or should a new ticket be created?

Perhaps a new version can be released with all the issue fixes that are currently in the DEV branch?

Thanks!

alison’s picture

100% agree with wylbur -- at a minimum, a new release with the PHP 7.2 fix, but a release with the latest version of DEV would be fantastic -- and I don't think I see any issues in the queue related to changes introduced in the DEV branch, right?

alison’s picture

Is there anything I or any of us can do to help get a release out?