edk12564 commented on PR #5744: URL: https://github.com/apache/fineract/pull/5744#issuecomment-4209784065
> > Hi @edk12564 and @adamsaghy, thank you for checking in. I am currently working on the final endpoints, though I'm facing a few minor issues with merge conflicts and checkstyle compliance after the recent rebase onto the 1.15.0 structure. I’m currently resolving these to ensure the build stays 'green' while I add the remaining IDs. I expect to have the updated PR submitted for review shortly. Thanks for your patience!" > > […](#) > > On Tue, 7 Apr, 2026, 11:06 pm edk12564, _**@**_._**> wrote: _edk12564_ left a comment ([apache/fineract#5744](https://github.com/apache/fineract/pull/5744)) <[#5744 (comment)](https://github.com/apache/fineract/pull/5744#issuecomment-4201026445)> Hi Sandro! Thanks for the comment. That's a really interesting point. It is true that once these operationIds are finished being added (remainder to be added by @Ambika-Sony https://github.com/Ambika-Sony and from here #5597 <#5597>), new endpoints in Fineract could result in deduplication again if named generically. If I am understanding correctly, your idea is to write a script that reads the fineract.json, compares it to a predefined spec, and makes edits to the generated fineract.json with operationIds generated from path + http method. Is that right? Overall I agree some kind of automated check better for future maintainability purposes. But we have to be careful with implementation. There might be a few problems: - we'd have t o update our predefined spec manually when new endpoints are added, since we cannot use the build to verify against itself - there are some edge cases where the method name does not properly convey the functionality. however, changing the method breaks other items in the codebase (for example, in batch steps which directly call endpoints). i was using operationId as a way of translating these bad method names into something usable for tests. for example, in FinancialActivityAccountsApiResource, we have createGLAccount. however, this endpoint actually just creates a mapping between a FinancialActivityAccount and a GLAccount that already exists. there is another createGLAccount that handles creating GL accounts. - path + http method might be too verbose. for example, retrieveTransactionByLoanExternalIdAndTransactionExternalId would become loansExternalIdLoanExternalIdTransactionsExternalIdExternalTransactionId(). I think looking over each endpoint and its functionality might take a lo ng time, but it's allowing me to properly translate these method names into usable names for tests. Which I think is still valuable. What do you think about this? — Reply to this email directly, view it on GitHub <[#5744 (comment)](https://github.com/apache/fineract/pull/5744#issuecomment-4201026445)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/BIN7S2GFFOE5RAHPQNIUC634UU4CBAVCNFSM6AAAAACXOZEDH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMBRGAZDMNBUGU . You are receiving this because you were mentioned.Message ID: _**@**_.**_> > > @edk12564 @Ambika-Sony Are you working on the same thing? which pr should be merged first? Hi there @adamsaghy. I think we should be working on different things. @Ambika-Sony requested to work on the Savings, Loans, Infrastructure, Organization, User Management related APIs so I made sure to avoid those in this PR. Should be good to merge! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
