Welp, in case anyone else has this problem and simply gets mocked for having a really cool browser theme <cough>@klincecum</cough>, I did figure this out. It’s largely as per the docs with a few twists:
Forget trying to use this with windows auth (LDAP). Probably Azure AD would work but we had to create separate basic auth users just for expenses.
Create a separate AppServer if your main one uses Windows auth. They don’t seem to play well together.
If you use RDS, publish your basic auth client so new users can log in with basic auth to change their password. They won’t be able to on their regular login. No idea if this would hold true in the client (we never use it) or the browser (ditto so far). On the server you can shift-click / log in as, but likely not getting all your remote team through to use the server.
Users must be set up as a unique Person/Contact linked to their user ID, and as a valid Employee linked to the Person / Contact. Then, in user admin, you select the Employee in the drop-down on the Company page. This part is covered very vaguely in the app setup guide.
For anyone but hourly / production staff, in Employee > Production you have to set expenses up to be “Indirect” (even if they’re not in Production). In Time and Expense > Expense > Detail, tick the Enter Expense box, and enter a default supplier. We’re still setting this up but it looks like we’ll use the credit card issuer for people with a company card, and those who don’t have one will be set up as their own supplier profile.
When entering the server address, don’t put the https://, don’t end with a /, and don’t leave a trailing space.
DNS and host files, port forwarding, SSL, etc have to be already set up for access both outside and inside your network, otherwise you’re adding an untraceable variable to your day.
Persevere. This is pure RESTful Epicor. It eventually works. Warts and all, there’s always a way, and it’s still a giraffe. Funny-looking, bigger than you think, but really, it’s remarkably graceful when it runs.
