Thank you James! Good thoughts re: moving content from wiki into asciidoc. Since it's just doc and not code, I think it's all the same as far as acceptance criteria for adding/deleting/changing these words, although of course the process for editing wiki pages is different than asciidoc text files. I guess I'm finding the asciidoc a bit better written and organized *and* I like that Securing Fineract wiki page, so it made sense to me to pull it in.
re: LDAP - that's a good example and a likely one. In this case I'd point future writers to fineract-doc/src/docs/en/chapters/security/index.adoc and suggest adding an LDAP/authorization section after the oauth section (under the line with include::oauth.adoc). And so on for other topics that would reasonably live in the Security chapter. Interesting you say "should" in "how should this be done?" -- we provide tips and ideas, not requirements and warranties. I'll try and clarify that a bit in my docs. re: CVEs -- fine by me. Personally I rarely dig into a historical CVE once I'm on a version with the fix, so I'd appreciate it being archived somewhere besides the main docs I'm presumably reading, editing, and referring to often. James Dailey wrote: > +1 on this effort. > > Let’s keep it simple for adding more advice… that was the benefit of the > wiki doc. If there’s an acceptance criteria implied for adding more > information, please share that rubric. Ie what are the extension points in > the documentation. > > Eg if a bank is running something like an LDAP server for existing roles > and they implement Fineract, what documentation would answer “how should > this be done?” Or “what RBAC exists and where is that documentation?” > > The security CVE fixes will continue to be listed on wiki and in email. > AFAIK >
