Re: Dates returned in ISO-8601 format ("2011-12-03T10:15:30Z") instead of as "May 3, 2020 10:51:19 PM" (FINERACT-926)

[James Dailey]

@Michael Vorburger 

+1 for your change.
Having dealt with date issues in other banking applications, I have come to
appreciate the ISO-8601 format.  If only everyone used the same date format
is a common lament.

I certainly hope no Mifos apps are using the US date standard.  But, if
they are, we should certainly modify them, rather than maintain a
non-standard output in the APIs.  my 2 cents.




On Sun, May 3, 2020 at 4:04 PM Michael Vorburger  wrote:

> Hello everyone,
>
> If you have a particular interest in the fascinating topic of how to
> represent dates in JSON responses of REST APIs such as Fineract's, and
> therefore have opinions about the code change proposed in
> https://github.com/apache/fineract/pull/816 which modifies the format in
> which certain dates are returned by the API in an incompatible way, then
> please read https://jira.apache.org/jira/browse/FINERACT-926 for full
> background, and comment either directly in that JIRA, or on this thread.
>
> The short version is that I'm proposing that certain date fields in
> Fineract's JSON API (those that internally come from java.util.Date
> instances, only) be formatted in ISO-8601 format e.g.
> "2011-12-03T10:15:30Z" instead of as e.g. "May 3, 2020 10:51:19 PM", as
> they are currently. If this could break any of your clients interpreting
> such Date fields, please shout now.
>
> NB that this this will NOT at all affect other date fields, such as those
> currently already formatted as e.g. "[2020, 05, 04]" (which internally come
> from org.joda.time.LocalDate instances).
>
> Tx,
> M.
> ___
> Michael Vorburger
> http://www.vorburger.ch
>

Re: New Policy about how to deal with unstable tests

[Michael Vorburger]

So I've had some "fun" on this front, and propose
https://github.com/apache/fineract/pull/817, which is the first step to
completely change how our integration tests tests await completion of
background jobs... code review feedback welcome!


On Sun, May 3, 2020 at 1:57 PM Awasum Yannick  wrote:

> Full disclosure, Petri first noticed this here
> 
>
> Also see: https://issues.apache.org/jira/browse/FINERACT-922
>
> On Sun, May 3, 2020 at 12:18 PM Awasum Yannick  wrote:
>
>> Looks like the flaky Integration tests failures is as a result of
>> schedule jobs taking too much time to complete so much that by the time an
>> assertion is done, the job history has zero completed jobs and we get in
>> some cases array out of bound exceptions due to 0 - 1 index. And in some
>> cases assertion errors.
>>
>> I will soon be sending a pr based on this and comments made else where.
>>
>> PS: sorry, am on mobile
>>
>> On Sat, May 2, 2020, 18:00 Michael Vorburger  wrote:
>>
>>> Saransh,
>>>
>>> yes, totally agree, of course fixing any failing test is the best, and
>>> any contributions for that would be very helpful.
>>>
>>> The point we are making with
>>> https://github.com/apache/fineract#pull-requests is obviously not ;)
>>> that we don't welcome help with fixing flaky tests, but simply that we
>>> cannot block people's PRs on anything else due to clearly unstable ITs. A
>>> project cannot stop parallel work and just grind to a complete halt because
>>> of some failing tests - as important as fixing failing tests ASAP is, yes,
>>> of course.
>>>
>>> I do meanwhile firmly believe that ignoring tests, IFF they are proven
>>> to be unrelated to a change proposed in a PR (as the README states), and
>>> then having separate investigations by interested parties to re-un-ignore
>>> any fixed tests, is the right strategy. Hope you agree?
>>>
>>> Best,
>>> M.
>>> ___
>>> Michael Vorburger
>>> http://www.vorburger.ch
>>>
>>>
>>> On Sat, May 2, 2020 at 6:17 PM Saransh Sharma 
>>> wrote:
>>>

 I investigated these tests, they are failing because of the
 interdependent nature of the application, Ignoring them eventually is not a
 better idea. Since the nature of the "flaky" test is unknown , are we sure
 that we might not encounter the same problem? in the next PR  or in the
 future PR's

 Points :

 1. I made some changes not related to anything to other packages

 Failed 3 of the tests . :) Pretty crazy , I think the status from the
 API is also returning 403 (is this normal don't think so.)

 https://api.travis-ci.org/v3/job/682216325/log.txt (Is this normal
 behaviour , plus local its quite different)

 Thus leading to this , "The following objects may have been
 concurrently modified in another transaction" It is clear that at the same
 time the transactions are happening.
 I would suggest that we group tests based on the packages and then
 perform functional tests based on the order of the dependency.

 Let me know, if at all we should try to resolve those test issues
 rather than putting Ignore.

 On Tue, Apr 28, 2020 at 10:00 AM James Dailey 
 wrote:

> +1
>
> "Please do NOT just @Ignore any existing tests mixed in as part of
> your larger PR."
>
> This seems like a key point to bring up to a higher level in the code
> review.  i.e. should there be a search for @Ignore when doing a code
> review?
>
>
>
>
>
>
>
>
> On Sun, Apr 26, 2020 at 2:30 AM Michael Vorburger 
> wrote:
>
>> Hello everyone,
>>
>> I propose https://github.com/apache/fineract/pull/782 as our New
>> Policy about how to deal with unstable tests (text proposed to be added 
>> to
>> the README in that PR is copy/pasted below for your reading convenience).
>>
>> Tx,
>> M.
>>
>> If your PR is failing to pass our CI build due to a test failure
>> which you suspect is a "flaky" test, and not due to a change in your PR,
>> then please do not simply wait for an active maintainer to come and help
>> you, but instead be a proactive contributor to the project, like this:
>> Search for the name of the failed test on
>> https://issues.apache.org/jira/, e.g. for
>> AccountingScenarioIntegrationTest you would find FINERACT-899
>> . If you find
>> previous comments "proving" that the same test has arbitrarily failed in 
>> at
>> least 3 past PRs, then please do yourself raise a small separate new PR
>> proposing to add an @Ignore to the respective unstable test (e.g.
>> #774 ) with the commit
>> message mentioning 

Dates returned in ISO-8601 format ("2011-12-03T10:15:30Z") instead of as "May 3, 2020 10:51:19 PM" (FINERACT-926)

[Michael Vorburger]

Hello everyone,

If you have a particular interest in the fascinating topic of how to
represent dates in JSON responses of REST APIs such as Fineract's, and
therefore have opinions about the code change proposed in
https://github.com/apache/fineract/pull/816 which modifies the format in
which certain dates are returned by the API in an incompatible way, then
please read https://jira.apache.org/jira/browse/FINERACT-926 for full
background, and comment either directly in that JIRA, or on this thread.

The short version is that I'm proposing that certain date fields in
Fineract's JSON API (those that internally come from java.util.Date
instances, only) be formatted in ISO-8601 format e.g.
"2011-12-03T10:15:30Z" instead of as e.g. "May 3, 2020 10:51:19 PM", as
they are currently. If this could break any of your clients interpreting
such Date fields, please shout now.

NB that this this will NOT at all affect other date fields, such as those
currently already formatted as e.g. "[2020, 05, 04]" (which internally come
from org.joda.time.LocalDate instances).

Tx,
M.
___
Michael Vorburger
http://www.vorburger.ch

Re: [Mifos-developer] Web-self-service app

[Eugene Adjei-Djan]

Sure I am willing to do so

On Sun, May 3, 2020 at 9:15 AM Awasum Yannick  wrote:

> Please..is anyone on this thread willing to make a PR to get this working
> for the rest the of the community? Eugene?
>
> On Sun, May 3, 2020 at 1:48 PM Eugene Adjei-Djan 
> wrote:
>
>> You’ll need to modify some part of the authentication code to pass
>> credentials in the body as per the modification of 1.4.
>>
>> Also work on the roles from the backend for permissions.
>>
>> Let me know if you know help.
>>
>> On Sun, May 3, 2020 at 8:37 AM Airsay Longcon 
>> wrote:
>>
>>> Hi Adjei,
>>> Please can you outline the steps to get it running. I have a test setup
>>> and I've been unable to run it side by side with the community app
>>>
>>> Sent from my iPhone
>>>
>>> On 3 May 2020, at 04:38, Eugene Adjei-Djan  wrote:
>>>
>>> 
>>>
>>>
>>> I have sorted it out with him, and now running on test beds.
>>>
>>> On Thu, Apr 30, 2020 at 9:43 AM Sendoro Juma 
>>> wrote:
>>>
 Dear Floyd,

 Mifos has partners in many countries.

 Please state your country and you can get support faster.



 > On 30 Apr 2020, at 12:39, Floyd Nickson 
 wrote:
 >
 > 
 > Hello, am looking for someone who can deploy mifos web-self-service
 and ensure that it's running.
 > Mifos-developer mailing list
 > mifos-develo...@lists.sourceforge.net
 > Unsubscribe or change settings at:
 > https://lists.sourceforge.net/lists/listinfo/mifos-developer

Re: [Mifos-developer] Web-self-service app

[Awasum Yannick]

Please..is anyone on this thread willing to make a PR to get this working
for the rest the of the community? Eugene?

On Sun, May 3, 2020 at 1:48 PM Eugene Adjei-Djan 
wrote:

> You’ll need to modify some part of the authentication code to pass
> credentials in the body as per the modification of 1.4.
>
> Also work on the roles from the backend for permissions.
>
> Let me know if you know help.
>
> On Sun, May 3, 2020 at 8:37 AM Airsay Longcon 
> wrote:
>
>> Hi Adjei,
>> Please can you outline the steps to get it running. I have a test setup
>> and I've been unable to run it side by side with the community app
>>
>> Sent from my iPhone
>>
>> On 3 May 2020, at 04:38, Eugene Adjei-Djan  wrote:
>>
>> 
>>
>>
>> I have sorted it out with him, and now running on test beds.
>>
>> On Thu, Apr 30, 2020 at 9:43 AM Sendoro Juma 
>> wrote:
>>
>>> Dear Floyd,
>>>
>>> Mifos has partners in many countries.
>>>
>>> Please state your country and you can get support faster.
>>>
>>>
>>>
>>> > On 30 Apr 2020, at 12:39, Floyd Nickson 
>>> wrote:
>>> >
>>> > 
>>> > Hello, am looking for someone who can deploy mifos web-self-service
>>> and ensure that it's running.
>>> > Mifos-developer mailing list
>>> > mifos-develo...@lists.sourceforge.net
>>> > Unsubscribe or change settings at:
>>> > https://lists.sourceforge.net/lists/listinfo/mifos-developer
>>>
>>>

Re: [Mifos-developer] Web-self-service app

[Eugene Adjei-Djan]

You’ll need to modify some part of the authentication code to pass
credentials in the body as per the modification of 1.4.

Also work on the roles from the backend for permissions.

Let me know if you know help.

On Sun, May 3, 2020 at 8:37 AM Airsay Longcon 
wrote:

> Hi Adjei,
> Please can you outline the steps to get it running. I have a test setup
> and I've been unable to run it side by side with the community app
>
> Sent from my iPhone
>
> On 3 May 2020, at 04:38, Eugene Adjei-Djan  wrote:
>
> 
>
>
> I have sorted it out with him, and now running on test beds.
>
> On Thu, Apr 30, 2020 at 9:43 AM Sendoro Juma  wrote:
>
>> Dear Floyd,
>>
>> Mifos has partners in many countries.
>>
>> Please state your country and you can get support faster.
>>
>>
>>
>> > On 30 Apr 2020, at 12:39, Floyd Nickson  wrote:
>> >
>> > 
>> > Hello, am looking for someone who can deploy mifos web-self-service and
>> ensure that it's running.
>> > Mifos-developer mailing list
>> > mifos-develo...@lists.sourceforge.net
>> > Unsubscribe or change settings at:
>> > https://lists.sourceforge.net/lists/listinfo/mifos-developer
>>
>>

Re: [Mifos-developer] Web-self-service app

[Airsay Longcon]

Hi Adjei,
Please can you outline the steps to get it running. I have a test setup and 
I've been unable to run it side by side with the community app

Sent from my iPhone

> On 3 May 2020, at 04:38, Eugene Adjei-Djan  wrote:
> 
> 
> 
> I have sorted it out with him, and now running on test beds.
> 
>> On Thu, Apr 30, 2020 at 9:43 AM Sendoro Juma  wrote:
>> Dear Floyd,
>> 
>> Mifos has partners in many countries.
>> 
>> Please state your country and you can get support faster.
>> 
>> 
>> 
>> > On 30 Apr 2020, at 12:39, Floyd Nickson  wrote:
>> > 
>> > 
>> > Hello, am looking for someone who can deploy mifos web-self-service and 
>> > ensure that it's running.
>> > Mifos-developer mailing list
>> > mifos-develo...@lists.sourceforge.net
>> > Unsubscribe or change settings at:
>> > https://lists.sourceforge.net/lists/listinfo/mifos-developer
>> 

Re: New Policy about how to deal with unstable tests

[Awasum Yannick]

Full disclosure, Petri first noticed this here


Also see: https://issues.apache.org/jira/browse/FINERACT-922

On Sun, May 3, 2020 at 12:18 PM Awasum Yannick  wrote:

> Looks like the flaky Integration tests failures is as a result of schedule
> jobs taking too much time to complete so much that by the time an assertion
> is done, the job history has zero completed jobs and we get in some cases
> array out of bound exceptions due to 0 - 1 index. And in some cases
> assertion errors.
>
> I will soon be sending a pr based on this and comments made else where.
>
> PS: sorry, am on mobile
>
> On Sat, May 2, 2020, 18:00 Michael Vorburger  wrote:
>
>> Saransh,
>>
>> yes, totally agree, of course fixing any failing test is the best, and
>> any contributions for that would be very helpful.
>>
>> The point we are making with
>> https://github.com/apache/fineract#pull-requests is obviously not ;)
>> that we don't welcome help with fixing flaky tests, but simply that we
>> cannot block people's PRs on anything else due to clearly unstable ITs. A
>> project cannot stop parallel work and just grind to a complete halt because
>> of some failing tests - as important as fixing failing tests ASAP is, yes,
>> of course.
>>
>> I do meanwhile firmly believe that ignoring tests, IFF they are proven to
>> be unrelated to a change proposed in a PR (as the README states), and then
>> having separate investigations by interested parties to re-un-ignore any
>> fixed tests, is the right strategy. Hope you agree?
>>
>> Best,
>> M.
>> ___
>> Michael Vorburger
>> http://www.vorburger.ch
>>
>>
>> On Sat, May 2, 2020 at 6:17 PM Saransh Sharma 
>> wrote:
>>
>>>
>>> I investigated these tests, they are failing because of the
>>> interdependent nature of the application, Ignoring them eventually is not a
>>> better idea. Since the nature of the "flaky" test is unknown , are we sure
>>> that we might not encounter the same problem? in the next PR  or in the
>>> future PR's
>>>
>>> Points :
>>>
>>> 1. I made some changes not related to anything to other packages
>>>
>>> Failed 3 of the tests . :) Pretty crazy , I think the status from the
>>> API is also returning 403 (is this normal don't think so.)
>>>
>>> https://api.travis-ci.org/v3/job/682216325/log.txt (Is this normal
>>> behaviour , plus local its quite different)
>>>
>>> Thus leading to this , "The following objects may have been
>>> concurrently modified in another transaction" It is clear that at the same
>>> time the transactions are happening.
>>> I would suggest that we group tests based on the packages and then
>>> perform functional tests based on the order of the dependency.
>>>
>>> Let me know, if at all we should try to resolve those test issues rather
>>> than putting Ignore.
>>>
>>> On Tue, Apr 28, 2020 at 10:00 AM James Dailey 
>>> wrote:
>>>
 +1

 "Please do NOT just @Ignore any existing tests mixed in as part of
 your larger PR."

 This seems like a key point to bring up to a higher level in the code
 review.  i.e. should there be a search for @Ignore when doing a code
 review?








 On Sun, Apr 26, 2020 at 2:30 AM Michael Vorburger 
 wrote:

> Hello everyone,
>
> I propose https://github.com/apache/fineract/pull/782 as our New
> Policy about how to deal with unstable tests (text proposed to be added to
> the README in that PR is copy/pasted below for your reading convenience).
>
> Tx,
> M.
>
> If your PR is failing to pass our CI build due to a test failure which
> you suspect is a "flaky" test, and not due to a change in your PR, then
> please do not simply wait for an active maintainer to come and help you,
> but instead be a proactive contributor to the project, like this: Search
> for the name of the failed test on https://issues.apache.org/jira/,
> e.g. for AccountingScenarioIntegrationTest you would find FINERACT-899
> . If you find
> previous comments "proving" that the same test has arbitrarily failed in 
> at
> least 3 past PRs, then please do yourself raise a small separate new PR
> proposing to add an @Ignore to the respective unstable test (e.g. #774
> ) with the commit
> message mentioning said JIRA (as always). Please do NOT just @Ignore
> any existing tests mixed in as part of your larger PR. If there is no
> existing JIRA for the test, then first please evaluate whether the failure
> couldn't be a (perhaps strange) impact of the change you are proposing
> after all. If it's not, then please raise a new JIRA to document the
> suspected Flaky Test, and link it to FINERACT-850
> 

Re: New Policy about how to deal with unstable tests

[Awasum Yannick]

Looks like the flaky Integration tests failures is as a result of schedule
jobs taking too much time to complete so much that by the time an assertion
is done, the job history has zero completed jobs and we get in some cases
array out of bound exceptions due to 0 - 1 index. And in some cases
assertion errors.

I will soon be sending a pr based on this and comments made else where.

PS: sorry, am on mobile

On Sat, May 2, 2020, 18:00 Michael Vorburger  wrote:

> Saransh,
>
> yes, totally agree, of course fixing any failing test is the best, and any
> contributions for that would be very helpful.
>
> The point we are making with
> https://github.com/apache/fineract#pull-requests is obviously not ;) that
> we don't welcome help with fixing flaky tests, but simply that we cannot
> block people's PRs on anything else due to clearly unstable ITs. A project
> cannot stop parallel work and just grind to a complete halt because of some
> failing tests - as important as fixing failing tests ASAP is, yes, of
> course.
>
> I do meanwhile firmly believe that ignoring tests, IFF they are proven to
> be unrelated to a change proposed in a PR (as the README states), and then
> having separate investigations by interested parties to re-un-ignore any
> fixed tests, is the right strategy. Hope you agree?
>
> Best,
> M.
> ___
> Michael Vorburger
> http://www.vorburger.ch
>
>
> On Sat, May 2, 2020 at 6:17 PM Saransh Sharma 
> wrote:
>
>>
>> I investigated these tests, they are failing because of the
>> interdependent nature of the application, Ignoring them eventually is not a
>> better idea. Since the nature of the "flaky" test is unknown , are we sure
>> that we might not encounter the same problem? in the next PR  or in the
>> future PR's
>>
>> Points :
>>
>> 1. I made some changes not related to anything to other packages
>>
>> Failed 3 of the tests . :) Pretty crazy , I think the status from the API
>> is also returning 403 (is this normal don't think so.)
>>
>> https://api.travis-ci.org/v3/job/682216325/log.txt (Is this normal
>> behaviour , plus local its quite different)
>>
>> Thus leading to this , "The following objects may have been concurrently
>> modified in another transaction" It is clear that at the same time the
>> transactions are happening.
>> I would suggest that we group tests based on the packages and then
>> perform functional tests based on the order of the dependency.
>>
>> Let me know, if at all we should try to resolve those test issues rather
>> than putting Ignore.
>>
>> On Tue, Apr 28, 2020 at 10:00 AM James Dailey 
>> wrote:
>>
>>> +1
>>>
>>> "Please do NOT just @Ignore any existing tests mixed in as part of your
>>> larger PR."
>>>
>>> This seems like a key point to bring up to a higher level in the code
>>> review.  i.e. should there be a search for @Ignore when doing a code
>>> review?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Apr 26, 2020 at 2:30 AM Michael Vorburger 
>>> wrote:
>>>
 Hello everyone,

 I propose https://github.com/apache/fineract/pull/782 as our New
 Policy about how to deal with unstable tests (text proposed to be added to
 the README in that PR is copy/pasted below for your reading convenience).

 Tx,
 M.

 If your PR is failing to pass our CI build due to a test failure which
 you suspect is a "flaky" test, and not due to a change in your PR, then
 please do not simply wait for an active maintainer to come and help you,
 but instead be a proactive contributor to the project, like this: Search
 for the name of the failed test on https://issues.apache.org/jira/,
 e.g. for AccountingScenarioIntegrationTest you would find FINERACT-899
 . If you find
 previous comments "proving" that the same test has arbitrarily failed in at
 least 3 past PRs, then please do yourself raise a small separate new PR
 proposing to add an @Ignore to the respective unstable test (e.g. #774
 ) with the commit message
 mentioning said JIRA (as always). Please do NOT just @Ignore any
 existing tests mixed in as part of your larger PR. If there is no existing
 JIRA for the test, then first please evaluate whether the failure couldn't
 be a (perhaps strange) impact of the change you are proposing after all. If
 it's not, then please raise a new JIRA to document the suspected Flaky
 Test, and link it to FINERACT-850
 . This will allow
 the next person coming along hitting the same test failure to easily find
 it, and eventually propose to ignore the unstable test. Then (only) Close
 and Reopen your PR, which will cause a new build, to see if it passes.

 ___
 Michael Vorburger
 http://www.vorburger.ch

>>>
>>
>> --
>>
>> Saransh Sharma
>> *Research Partner*
>> *Muellner Internet 

Re: Docker Compose now includes UI from Community App!

[Michael Vorburger]

On Sun, 3 May 2020, 00:50 Scott Dunbar,  wrote:

> For those that might run across it - to use the UI you must first go to
> https://localhost:8443/ and accept the self-signed cert.  Otherwise you
> get a message that is rather misleading.
>

Great point! Would you like to raise a PR to add this tip to the README?

I'm curious why it isn't easier to just use http for test environments?
>

The Fineract API enforces using https through an automatic redirect from
http, so the problem you describe would probably still happen? Try it.

Unless someone wants to contribute something to run only with http, like a
Spring Profile, for Dev. The"danger" is that someone somewhere will then
run a production instance like that, if it's easy enough... ;-)

  The error in the browser and the error in the developer tools do not give
> much of an indication as to the underlying nature of the problem in at
> least current Firefox and Chrome browsers.
>
>
>
> On Sat, May 2, 2020 at 6:31 AM Michael Vorburger 
> wrote:
>
>> Hello everyone,
>>
>> Shout out to Nasser for having contributed the just merged PR #787
>>  (also note #791
>> ) for
>> https://issues.apache.org/jira/browse/FINERACT-845.
>>
>> With this, it's easier than it has ever been before in the history of
>> this project to locally spin up the latest and greatest version of Apache
>> Fineract + also latest version (!)) of the web UI from the Community App:
>>
>> git clone https://github.com/apache/fineract.git
>> cd fineract
>> docker-compose build
>> docker-compose up -d
>>
>> Now login with default *username* mifos and *password* password on
>> http://localhost:9090/?baseApiUrl=https://localhost:8443/fineract-provider=default
>> .
>>
>> Best,
>> M.
>>
>> PS: https://www.fineract.dev will soon similarly automatically run the
>> very latest code in the cloud (this thread is about something similar for
>> local use using docker compose).
>> ___
>> Michael Vorburger
>> http://www.vorburger.ch
>>
>
>
> --
> Scott Dunbar
> Cell: 303 667 6343
>