Thank you for your prompt response, it is part of the reason I decided this product could work for us.
I can't say I noticed many hints about looking for the "application help pages". I probably saw it, but as I'm learning the jargon as I go, it's difficult to grasp what everything means.
I've found it is difficult to architect the product without really deep diving into it (example below)
It is certainly against the grain to prefer more intrinsic documentation than online documentation. It may help others understand if you could explain why automated documentation is a prerequisite, however I am respectful and understanding of your team's position, resources and business decisions. I don't understand enough of your approach to provide any further constructive criticism.
As I don't really code anymore, I can offer as my contribution that if you setup a Wiki infrastructure, I will put in the work to transfer the documentation in it's current state, add some of the challenges I encountered during design, setup/recompiling and improve minor bits and pieces.
Then if your team is happy with it, you can publish it and replace the intrinsic documentation to refer to the online docs, which then becomes the sole source of authority (unless that is part of the automated documentation problem...?).
Either way, I can see us using this indefinitely so thank you 🙂
...................................
For example, the use case for Oauth2 with M365 is limited by the mail rules, in that the filtering (currently) only applies to the sender email address, not the recipient. Therefore if one requires multiple email addresses, e.g. support@x.com, and info@x.com, to share the same license (because there's no point paying per license per login for each team/department), the more efficient way to do this is to filter the mail before it hits the mailbox, or alternatively apply mail transport rules for the application to pick up like prefixing subject lines.
Then the solution design problem presents: one needs to filter the mail prior to the application 'mail filter', or alternatively modify the app to do as the solution requires.
Option 1: Filter the mail first
Mail transport rules can modify e.g. the subject for regex to pick up. Exchange Online has very powerful rules, much more than one could expect REI3 to include. However another challenge presents as a simple subject prepend will cause excessive subject lengths in tickets with much correspondence.
One could also put an IMAP server in front on a subdomain or mail redirection, but this means additional infrastructure and then also negates the use case for Oauth2 (let's exclude the other paywall features from this scope) because you'd have a fully functioning mail server that doesn't require Oauth2 anyway. However, it does add additional complexity in troubleshooting mail-flow.
Option 2: Modify code yourself
Not a great option as it's a core app and any upgrade to the app will break the changes made. Could submit a pull request, but this requires learning how to build apps in this framework. Basically one needs to be a competent contemporary dev to be able to do this.
Option 3: Pay for the mod
Not many can justify paying for custom mods to adopt software that, while growing rapidly, is respectfully quite immature in the grand scheme. As the idiom goes, nobody gets fired for installing IBM, Microsoft, other big name etc.
I opine that this kind of design decision should be able to be made from reading the docs and deciding before conducting a Proof of Concept, and I'm happy to contribute something to this aspect of the project.
...................................
