Regarding managing user expectations with respect to API and DS working with AD is to register a JIRA issue for each of the not working controls. The advantages are that both users and community members would then now where the products stand.
And if and when one gets fixed it'll turn up in the release notes. Best regards, Pierre Smits *OFBiz Extensions Marketplace* http://oem.ofbizci.net/oci-2/ On Mon, Oct 19, 2015 at 10:52 AM, Emmanuel Lécharny <[email protected]> wrote: > Le 19/10/15 10:30, Radovan Semancik a écrit : > > On 10/19/2015 02:23 AM, Emmanuel Lécharny wrote: > >> I think we can wait for another release, that may come quite quickly > >> (I have myself some additional fixes for the LdifAnonymizer). > > > > OK. No problem. Just let me know when the M32 release is done so I can > > commit my code. > > I'll close the vote tonite, afte rmy day job ;-) > > > >> Regarding the missing controls/extOps, here is what I would suggest : > >> we could spend some time implementing a batch of the missing AD > >> elements, and cut a release as soon as it's done. > > > > Hmm, but there is a problem. It does not make much sense to implement > > the controls "theoretically". They have to be tested with real AD > > instances. We all know how AD "works", eh? > > Meh... So right. OTOH, there is nothing forbidden us to get the code > added, with internal tests, for someone to test it against AD. > > > > So I would counter-propose to implement the controls gradually when > > someone needs them and someone is able to test them. This is the case > > for the "Deleted" control: I need it and I have a setup to test it > > with real AD instance. Yes, this specific control is trivial. But > > there are quite complex controls in the AD set ... > > I have yet checked teh syntax for all of them. > > What I would suggest here is to create either one JIRA for all the AD > controls/extended, or one JIRA per control/extended. The second option > might be a better solution, even if that mean 50 JIRA will be created > (OTOH, closing them fast wikll improve our opened/closed ration in a > nice way ;-) > > > >> For controls, it's not necessarily complex, it's just a bit time > >> consuming (especially the tests). > > > > Well, yes, unit tests are a bit time consuming. But tests with real AD > > are insanely time consuming as AD will not tell you what is the > > problem. So, unless you already have a setup where you can test it > > easily I see no point in implementing something that will not be tested. > I don't have any AD close to me, so I have to trust you on that :-) > > > > >> The only part I'm not sure of is which ones should we include and > >> which ones should we ignore. I suspect we should go to the full > >> extent and make the API as complete as possible... > > > > For me it is the "Deleted" control now. Maybe SD_FLAGS a bit later. > > Ok, let's go for the first one quickly then. > >
