[Feature] RuleForEach Property builder

I think the following might be much more pleasant to write:
💛
RuleForEach(s => s.Lines)
                .Property(s => s.DollarAmount)
                .GreaterThanOrEqualTo(0);

❌
RuleForEach(s => s.Lines)
                .Must(s => s.DollarAmount > 0)
                .WithMessage((s, x) => $"LineNumber {s.LineNumber} {nameof(s.Lines)} must have {x.DollarAmount} greater than 0.");

Granted, it's not 1:1 and the bottom example has some additional context, but you get the idea of basically letting users "recurse down an object model" and re-use the already unit tested FluentValidation validation rules.
By the way, Jeremy, the overloads on WithMessage is a nice touch!  It's pretty amazing to use a library and wonder "gee, I wonder if I just type it this way if it will just work", and IT DOES!

I also just noticed that in typing the Must syntax, I have a bug where I put > instead of >=, which I think just speaks to how much I would prefer using intellisense and FluentValidation builder API

The usual approach with FluentValidation isn't to decare rules for nested properties inline, but to use child validators, so this probably isn't something we'll include in the core. That being said, you can add this behaviour with an extension method if you'd like to have it in your project:
public static IRuleBuilderInitial<TProperty, TChildProperty> Property<T, TProperty, TChildProperty>(this IRuleBuilder<T, TProperty> rule, Expression<Func<TProperty, TChildProperty>> expr) {
	var inlineValidator = new InlineValidator<TProperty>();
	return inlineValidator.RuleFor(expr);
}

The problem with this approach though is that once you're at the property level, the contextual informaton about the parent has been lost. Meaning this would not be possible:
RuleForEach(s => s.Lines)
  .Property(s => s.DollarAmount)
      .GreaterThanOrEqualTo(0);
  .Property(s => s.SomethingElse)
      .NotNull();

...and instead you'd have to do this:
RuleForEach(s => s.Lines)
  .Property(s => s.DollarAmount)
      .GreaterThanOrEqualTo(0);

RuleForEach(s => s.Lines)
  .Property(s => s.ProductName)
      .NotNull();

...which is more expensive as it requires iterating the collection twice, so it's not really that practical.
You could just use an inline validator directly if you don't want a separate child validator class:
RuleForEach(x => x.Lines).SetValidator(new InlineValidator<Order> {
  orderValidator => orderValidator.RuleFor(x => x.DollarAmount).GreaterThanOrEqualTo(0),
  orderValidator => orderValidator.RuleFor(x => x.ProductName).NotNull(0),
});

(Basically that's doing the same as Property is doing internally, but isn't then limited to a single property)

I'll have to do some digging; I was initially thinking I could use the same trick WithMessage is using, but in reverse.  In effect the builder is accumulating phantom information that isn't useful to the current builder, but could be useful for other builders (e.g., the next property).
Am I missing something obvious?

The problem is that once you’re at the level of an individual property, the builder interfaces would require knowledge of the parent type in order to go up to a previous level, or to jump to a different property. This would require an additional type parameter in the rule builder interfaces which is a breaking change both internally and for external consumers.

I was thinking internally it would mean a lot more tests; whether it is worth the benefit is certainly open to debate.
For external consumers, I agree, if they've created an extension method with an additional type parameter, it would break them.
However, in the general case, it would just be an extra set of APIs - but again, the downside is way more code to maintain, and I know you have explained to me the cost on your life of maintaining this library, and your life quality is a feature I can't underrate.

As this has been the recommended extensibility method for nearly 10 years, this would have a major impact across the user base. I don't see how this is worth breaking so many consumers when there are already alternatives that accomplish this.

I guess my thinking was, Resharper has come such a long way, I barely have to type any more to get stuff done.  I just type "rf" and get RuleFor handed to me, etc.  The whole thing is a dream world.  And I'm only on Resharper ultimate 2018.3.4 - i'm not even on 2019.1 yet.
I guess if there was a .SetValidator<T> where T : new, IValidator extension method, that would let me use Resharper Create From Usage automations and be about as productive. THoughts?

Syntactically that'd be messy - you wouldn't be able to use type inference so all the generics would have to be specified explicitly in the call to SetValidator.
class FooValidator : AbstractValidator<Person> {
  public FooValidator() {
    RuleFor(x => x.Address).SetValidator<Person, string, AddressValidator>();
  }
}

public static class Ext {
	public static IRuleBuilderOptions<T, TProperty> SetValidator<T, TProperty, TValidator>(this IRuleBuilder<T,TProperty> rule) where TValidator : IValidator<TProperty>, new() {
		return rule.SetValidator(new TValidator());
	}
}

You're welcome to implement that in your own project if you like, but that's not something I'm interested in having in the core project. Using SetValidator(new AddressValidator()) (or injecting it via the constructor) is much clearer,  and let's be honest, it's only a few keystrokes.

Yeah, sometimes I shake my head at how hard I try to avoid a few keystrokes.  Can you blame me?  I just finished typing up some EFCore code-first migrations for a database-first project.  Legitimately, had a tweet-worth conversation with a co-worker.
Me: Ah, too much typing.
Him: Do your hands ache?
Me: Yeah. Does that ever happen to you? (He's 10 years younger.)
Him: Yeah, only when I work with EFCore.
😆

Rather than chaining multiple calls to Property (which we've established is a massive change), an alternative would be to allow child rule definitions within a callback. This would not be a breaking change, it wouldn't require a rewrite and is also consistent with the existing syntax for both DependentRules and ForEach. It'd look something like this:
RuleForEach(x => x.Lines).ChildRules(line => {
  line.RuleFor(x => x.DollarAmount).GreaterThanOrEqualTo(0);
  line.RuleFor(x => x.ProductName).NotNull();
});

Not quite sure of the method name yet, but I think ChildRules makes the most sense and is conistent with DependentRles. Basically this would just act as a wrapper around the InlineValidator syntax I mentioned above.
Would that work for you?

That's very elegant. Yes.  You amaze me, Jeremy!

I'll add it for the next release. If you want to start using it before then, you can add it as an extension method:
public static IRuleBuilderOptions<T, TProperty> ChildRules<T, TProperty>(this IRuleBuilder<T, TProperty> ruleBuilder, Action<InlineValidator<TProperty>> action) {
	if (action == null) throw new ArgumentNullException(nameof(action));
	var validator = new InlineValidator<TProperty>();
	action(validator);
	return ruleBuilder.SetValidator(validator);
}

Neat! Could also have a overload which "lifts" InlineValidator into a generic argument similar to what I asked for.  Pseudo-code would be something like:
public static IRuleBuilderOptions<T, TProperty> ChildRules<TValidator, T, TProperty>(this IRuleBuilder<T, TProperty> ruleBuilder) where TValidator : new, InlineValidator<T>
{
	var validator = new TValidator<TProperty>();
        // magic goes here
	return ruleBuilder.SetValidator(validator);
}

I might play with this some to get it to work.

There’s not really any point. You’d lose the type inference so all the generics would have to be specified explicitly. At that point you may as well just instantiate it directly and pass it to SetValidator.

Yeah, but I have further ideas using another library to scrap that boilerplate.

Hmm.  @JeremySkinner - Any idea why this doesn't work?  I'm not sure if it's a shortcoming in the TestHelper not working on rule collections, or if it's an issue with the ChildRules extension.
Written as a Linqpad query:
using Xunit;
using FluentValidation;
using FluentValidation.TestHelper;

void Main()
{
	new DepartmentValidatorTests().TestChildRulesValidations();
}

public static class FluentValidationExtensions
{
	public static IRuleBuilderOptions<T, TProperty> ChildRules<T, TProperty>(this IRuleBuilder<T, TProperty> ruleBuilder, Action<InlineValidator<TProperty>> action)
	{
		if (action == null) throw new ArgumentNullException(nameof(action));
		var validator = new InlineValidator<TProperty>();
		action(validator);
		return ruleBuilder.SetValidator(validator);
	}
}
public class Person
{
	public string Name { get; set; }
}
public class Department
{
	public ICollection<Person> Persons { get; set; }
}
public class DepartmentValidator : AbstractValidator<Department>
{
	public DepartmentValidator()
	{
		RuleForEach(x => x.Persons).ChildRules(s => s.RuleFor(x => x.Name).MaximumLength(50));
	}
}
public class DepartmentValidatorTests
{
	[Fact]
	public void TestChildRulesValidations()
	{
		var badName = string.Join(string.Empty, Enumerable.Repeat("A", 51));
		var validator = new DepartmentValidator();
		validator.ShouldHaveValidationErrorFor(x => x.Persons, new List<Person>()
			{
				new Person() { Name = badName }
			});
	}
}

I think the issue is likely in TestHelper; to reduce complexity I changed the DepartmentValidator to use existing API features:
public class DepartmentValidator : AbstractValidator<Department>
{
	public DepartmentValidator()
	{
		RuleForEach(x => x.Persons).SetValidator(new InlineValidator<Person> {
			s => s.RuleFor(x => x.Name).MaximumLength(50)
		});
	}
}

By the way, it works fine in the scenario when Persons is a List<string>.  However, when it has to go down one more level, it seems to not work any more.  I can't quite see the problem with my naked eyes at the moment.
void Main()
{
	new DepartmentValidatorTests().TestChildRulesValidations();
}
public class DepartmentFlat
{
	public ICollection<string> Persons {get; set;}
}
public class DepartmentFlatValidator : AbstractValidator<DepartmentFlat>
{
	public DepartmentFlatValidator()
	{
		RuleForEach(x => x.Persons).SetValidator(new InlineValidator<string> {
			s => s.RuleFor(x => x).MaximumLength(50)
		});
	}
}
public class DepartmentValidatorTests
{
	[Fact]
	public void TestChildRulesValidations()
	{
		var badName = string.Join(string.Empty, Enumerable.Repeat("A", 51));
		var validator = new DepartmentFlatValidator();

		validator.ShouldHaveValidationErrorFor(x => x.Persons, new List<string>()
			{
				badName
			});
	}
}

NOTE: I'll probably hack a bit more on this this week, so I don't want you to stress out thinking I'm depending on you for an answer.  I suspect the issue is this line in the TestHelper logic:
    public static IEnumerable<ValidationFailure> ShouldHaveValidationErrorFor<T, TValue>(
      this IValidator<T> validator,
      Expression<Func<T, TValue>> expression,
      TValue value,
      string ruleSet = null)
      where T : class, new()
    {
      T instanceToValidate = new T(); // T here is DepartmentFlat
      return validator.TestValidate<T, TValue>(expression, instanceToValidate, value, ruleSet, true).ShouldHaveError<T, TValue>();
    }

Note to self: The problem might be a bit more obvious if I switch to Michal Jankowskii's third party test helper library.

@JeremySkinner Have a look at my demoes above - I think the InlineValidator<T> abstraction isn't compatible with the current FluentValidation.TestHelper API.

The test helper is actually working correctly here. The rules you have defined are child rules - they're associated with the individual properties (eg "Name"), they're not associated with the whole collection, but your test is expecting the errors to be associated with the whole collection property.

Implemented for 8.5.

8.5-preview2 is now released with this change.


Dashboard 3.9

Description
Ember 3.9 Navi Dashboards Upgrade
Proposed Changes

ember-cli-update changes and codemods
use ember-promise-helpers instead of promise proxy properties
normalize arrays in line-chart

package lock has ouroath.


Getting error successCallback is not a function

Error in Success callbackId: serviceDiscovery1097938893 : TypeError: successCallback is not a function

Hi,
What platform are you developing on (iOS/Android)?
Can you send me an example of how you are calling the serviceDiscovery API?
Thanks

Android.
Recently I was trying to migrate to new ionic 2+ version.
I copied entire code and also updated to latest SSDP plugin.
Now when i run , im getting this error,
everything looks in place. butn dont know why it throwing this error .
	$scope.RunDiscovery = function()
	{
		console.log("im in scan discovery...");
		$scope.show();
		try {
			serviceDiscovery.getNetworkServices(serviceType, true, $scope.fsuccess, $scope.ffailure);
		}
		catch(err) {
			console.log(err+' - Error in SSDP');
			$scope.hide();
			$scope.$broadcast('scroll.refreshComplete');
		}

	}
	$scope.fsuccess = function(devices)
	{
		//store.set('board',devices);
	}

	$scope.ffailure = function()
	{
		console.log("Failed..");
	}

The API has changed slightly since your implementation. Some refactoring took place and as a result the GET request for the config.xml is now handled in the native code instead of the JS. So the 2nd param is no longer necessary.
serviceDiscovery.getNetworkServices(serviceType, true, $scope.fsuccess, $scope.ffailure);
Change to:
serviceDiscovery.getNetworkServices(serviceType, $scope.fsuccess, $scope.ffailure);


fix twitter id rounding

Issue #, if available:
I found that rounding occurred because Twitter IDs are represented as 64-bit integers.
https://developer.x.com/en/docs/x-ids
{
  **id:<PHONE_NUMBER>51234800,**. 　　＜ーrounding！！
  **id_str: '123437477851234793',**. 　　　＜ーTrue ID
  name: 'cossy',
  screen_name: 'aaaaa',
  location: ''

~~~~
}

Description of changes:

Consolidate @aws-prototyping-sdk and others into @aws/pdk

https://aws.github.io/aws-pdk/getting_started/migration_guide.html

Changed version containing several vulnerabilities
Changed to save id_str instead of id returned from Twitter api

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

LGTM


[Scheduler] Adding timeout to tasks

We are running into problems testing targets in source.  Some go off and never complete.  Adding a configurable timeout via the scheduler on tasks.  Once the timeout is reached the scheduler will mark the task as completed, but it will be marked with Status TIMEDOUT.

I also made the Polling Period Configurable while I was in that code.
fixed default config name in scheduler main.go since that never got updated with @dbentley changes.
Renamed MakeRPCWorkerFactory to Create() to be consistent with the rest of the config objects

Current coverage is 63.91% (diff: 100%)

Merging #145 into master will increase coverage by 0.18%

@@             master       #145   diff @@
==========================================
  Files            61         61
  Lines          2622       2633    +11
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           1671       1683    +12
+ Misses          833        832     -1
  Partials        118        118

Powered by Codecov. Last update 2493db7...eb757b7


[Improvement][dolphinscheduler-api] Make ADMIN user a "memberOf" when using LDAP server

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description
The currently implementation will only llow one user to be ADMIN for a scheduler instance using the attribute
security.authentication.ldap.user.admin=read-only-admin
Further more the revoke/invoking must be done changing the dolphin config. In large organisation this will done through roles/groups.
Therefore, I would like to be assign admin access using LDAP groups ("memberOf" attribute)
So can we extend the code (keeping the old way too), but also add chacke like "mail" attributes
    security.authentication.ldap.user.admin-attribute=membmerOf
    security.authentication.ldap.user.admin-value=cn=dolphinAdmin,dc=....etc...

https://github.com/apache/dolphinscheduler/pull/16105
Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Improved feature buy replacing "admin-attribute" and "admin-value" to "admin-filter" so a filter check is applied to find admin users. This will enable different LDAP setup for ROLES. The filter makes it very generic to identify the ADMIN role
For the "ldap.forumsys.com" were we make all scientist admins
security.authentication.ldap.user.admin-filter=(&(ou=scientists)(uniqueMember=uid={0},dc=example,dc=com))
to the use of "memberOf" assigning of roles.
(security.authentication.ldap.user.admin-filter=&(sAMAccountName={0})(memberOf=CN=admin,OU=dolphin,DC=example,DC=com)


Inconsistency in manual for distribution installation

https://github.com/metafacture/metafacture-core#building-metafacture-core-from-source
says to use:
$ ./gradlew install
https://github.com/metafacture/metafacture-core/wiki/Flux-user-guide#installing-flux
says to use:
./gradlew installDist
Which is right? Should be consistent in documentation

Hm, I don't see inconsistencies here - but let's try to fix the confusion.
Maybe your view of just an "installation" guide is not quite that proper in that respect that many READMEs provide an "Installation" AND a "Usage" section. The latter provides only the flux-wiki page.
I think we should in general keep the README rather short (that's more of an effort because we have Flux and pure java resp. library).
a) Maybe we should provide an usage example for both (flux and java) in the README , or/and maybe we should also add a wiki-page for java installation and usage like for the flux (I vote for both proposals with a short java code example and a corresponding flux  in the README).
Let's go into more details here to explain why a) may be a good solution:
The flux wiki page states in the first paragraph:

Metafacture as a stand-alone application

So there are mostly non-developers addressed (well, for completeness sake it's also mentioned how to use the Flux from/as a Java class (3.1)
So you see that the dichotomy of "stand-alone" and "non-programmer" is not quite true if it comes to comprehensiveness (why do you want to use Flux.java ? E.g. if you want to debug a flux workflow).
In the README I just added a link to the comprehensive flux wiki page) without removing the (redundantly) short introduction in the README of how to install flux stand-alone, so users still have a quick overview there of what's possible.
For developers the README explains just how to:

use the Java libary as a maven project (by configuring maven central releases in the pom)
how to build your own branch and install it into the local maven repository

If I gather that correctly you would rather want to have just one page (the README then) where these different kinds of installations and usages are described. I think it would be too much in the README to add the comprehensive (and even more exapandable) flux-how-to (aka the wiki page), but I am good with a proposal like b) "let's put just a link in the README to the flux wiki page instead of have some guide redudantly").
As noted above,  the installation guide in the README comes short of a (comprehensive) usage (with examples and so on) for using metamorph as a library.  There is not even a (direct) link to an example. The experienced coder may have a look in the test directories but I agree that something like https://github.com/hbz/metafacture-java-examples/blob/master/src/test/java/samples/Sample1_PrintData.java would be nicer (whereas https://github.com/hbz/metafacture-java-examples I don't like for when clicking on "src/main/java" the directory is empty  which is confusing).
So yeah, we have a lot to restructure/link re docu in general.
Let me ask, how are you confused exactly (from the perspective of a non-programmer) in using metafacture starting from the repo's README ? And what about proposal a)  an/or  b) or maybe you have some alternative proposal?


Docker compose for test; Fix keys on delete_topics

Resolve #90

Thanks for the pr. One last thing. Please help to update changelog.md

@zmstone I wasn't sure which version you would like to use next. Just picked the smallest next version.