Hi Felix, welcome to the community. Thanks for your effort thus far in finding these bugs and attempting to report them. I will go try to ping some of the committers and maintainers to review your PRs and respond to inquiries above.
Regarding the approval of JIRA account, I haven't seen anything come into the approval queue since you're getting the error message blocking you from submitting. Have you tried via another browser? I can try to submit for you as well. Ed On Mon, Feb 17, 2025, 05:59 Aleksandar Vidakovic <chee...@monkeysintown.com> wrote: > ... can someone with enough Karma help Felix to get an account on Jira? > > @Ed Cable <edca...@mifos.org> @James Dailey <jdai...@apache.org> ? > > On Mon, Feb 17, 2025 at 2:51 PM Felix van Hove <fvanh...@gmx.de.invalid> > wrote: > >> Hi everyone, >> >> I'm a Salesforce and Java developer, and have recently started >> contributing to the Mifos project (my 2 PRs are still not dealt with, >> but never mind). I might also want to start contributing to Fineract. >> >> I've tried to sign up to your Jira - see screenshot. But I've got the >> error message >> >> > Your Jira username contains invalid characters, or is too long >> >> I've shortened my actual name etc., but nothing helped. What is wrong >> with me? >> >> One reason I wish I had an account is that I would like to file a bug >> report. You can see the history of the bug on Slack, where someone >> attempted to create a simple group via the Mifos client. This failed >> with the following stack trace on the side of Fineract: >> >> --- snip --- >> java.lang.NullPointerException: Cannot invoke "String.equals(Object)" >> because "entityType" is null >> at >> >> org.apache.fineract.portfolio.account.service.AccountNumberGenerator.checkAccountNumberConflict(AccountNumberGenerator.java:200) >> at >> >> org.apache.fineract.portfolio.account.service.AccountNumberGenerator.generateAccountNumber(AccountNumberGenerator.java:175) >> at >> >> org.apache.fineract.portfolio.account.service.AccountNumberGenerator.generateGroupAccountNumber(AccountNumberGenerator.java:243) >> at >> >> org.apache.fineract.portfolio.group.service.GroupingTypesWritePlatformServiceJpaRepositoryImpl.generateAccountNumberIfRequired(GroupingTypesWritePlatformServiceJpaRepositoryImpl.java:243) >> at >> >> org.apache.fineract.portfolio.group.service.GroupingTypesWritePlatformServiceJpaRepositoryImpl.createGroupingType(GroupingTypesWritePlatformServiceJpaRepositoryImpl.java:198) >> at >> >> org.apache.fineract.portfolio.group.service.GroupingTypesWritePlatformServiceJpaRepositoryImpl.createGroup(GroupingTypesWritePlatformServiceJpaRepositoryImpl.java:274) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> --- snip --- >> >> I had a look into the AccountNumberGenerator.java. It's clear that this >> user's c_configuration table had random-account-number=enabled. This >> might explain, why the problem hasn't popped up before. In its current >> state, the method checkAccountNumberConflict requires "entityType" to be >> in some property map. But if you look up the call stack, the entityType >> can't be in the map. The map is built in line 240ff. >> >> The same bug affects two other public generate* methods of this class. >> They need to be adjusted too. (And why are there two public methods at >> the bottom of the class? I suggest to move them up to the other public >> methods.) For people working with random account numbers, this looks >> like important. >> >> Kind Regards from Marseille, >> Felix van Hove >> >
