|
hasorli hasorli@web
|
100420505633
|
5 years ago
|
|
|
|
brett
|
3b90ef14d197
|
8 years ago
|
|
|
|
brett
|
6d09a3097f69
|
8 years ago
|
|
|
|
brett
|
322ad21f8b02
|
8 years ago
|
|
Change "In Progress" state to "Draft".
Payment requests are basically always "in progress" until they're rejected or the requestor receives payment. Use a name that better reflects what's going on.
|
|
brett
|
d8a932b4622f
|
8 years ago
|
|
|
|
brett
|
98b5bc47fa74
|
8 years ago
|
|
|
|
brett
|
60aba5b03bc6
|
8 years ago
|
|
Policy validation can wait until after the first release.
The policy validations that would help reduce back and forth most are the ones that are hard to implement: checking that attachments actually include the necessary information, checking that per diems match limits, etc. Building to be able to accommodate these is going to take time, and we don't need to make all that investment for the first release.
|
|
brett
|
341cf7c85b9c
|
8 years ago
|
|
|
|
brett
|
f9cb44d5f49c
|
8 years ago
|
|
|
|
brett
|
49efe41741d4
|
8 years ago
|
|
Pre-approval can wait until after the first release.
This is a very valuable feature, and we want it soon, but it doesn't have to be in literally the first release.
|
|
bkuhn
|
d921c03d6f69
|
8 years ago
|
|
They aren't possible, but maybe are necessary.
I agree that all the items listed in here aren't possible given the time allotted for development, and I haven't tried to integrate any of them into the main feature set to avoid feature creep. However, some of them are going to be necessary, and early users may need to realize that some out-of-band workarounds will be necessary in the first version, because the features listed here were, well, necessary. :)
|
|
bkuhn
|
5d36d905e56d
|
8 years ago
|
|
Ensure user freedom for Javascript.
The fundamental point here probably goes without saying given who the project leader is. ;)
The LibreJS thing may end up to be nice-to-have. LibreJS has some serious problems -- I've had difficulty getting websites to work with the plugin because the LibreJS plugin makes overly simplistic assumptions about how Javascript is often deployed on a website.
But, we should try to be compatible if it's possible.
|
|
bkuhn
|
0792a933b272
|
8 years ago
|
|
|
|
bkuhn
|
7f96a1217616
|
8 years ago
|
|
Wordsmith,grammar, and formatting changes.
No substantive change here, just writing style, grammar, and formatting changes.
|
|
bkuhn
|
332234832919
|
8 years ago
|
|
Additional wishlist for currency stuff.
The currency stuff is going to be complicated, but I agree completely we should leave it wishlist'ed.
|
|
bkuhn
|
3f2f76019bc3
|
8 years ago
|
|
Plural pronouns for singular annoys me. I really believe in gender fairness and fluidness in prounouning, and I get why "they" is always better to use, and that the "one's request" construction is too tortured. So, I tend to just write everything in plurals if possible which keeps 'they' but makes the number grammatically agree. Yes, I know that the ADT made "they/them used as singular" as 2015 word of the year. (see https://en.wikipedia.org/wiki/Word_of_the_year#American_Dialect_Societyso maybe some nun slapped the table too hard with her ruler when made some plural/singular mistake with a pronoun when I was in grade school, but I have a compulsive need to change everything to plural when I see "they" and am editing a document. ;)
|
|
bkuhn
|
6e91d81ce1cc
|
8 years ago
|
|
Additional request state: Pre-Approval
Many travel policies, for example, require that certain expenses be approved before tickets can be purchased. An example from Conservancy's travel policy include: hotel bookings beyond the GSA/Dept-of-State Per Diem hotel rate, and flights that exceed the with-$100-of-cheapest rule.
As such, requestors need the ability to request preapproval.
These changes herein committed, however, do *not* account for the fact that a request may already be "In Progress" when another expense comes up. An example of that is a flight was booked already in policy and the requestor, and uploaded, and the requestor then discovers later that the hotel is out-of-policy and needs preapproval. We can perhaps ignore this scenario for the first specification of this to avoid feature-creep, but I wanted to flag it as a potential issue for future.
The work around might be that the Bookkeeper is allowed to move a request between any state to another, so the work-around in this specific instance may have to require an out-of-band conversation between bookkeeper and requestor. That's not disaster.
|
|
bkuhn
|
cb902d08af28
|
8 years ago
|
|
member => requestor
The requestor for payment may or may not be a member or affiliated in some way with the organization.
|
|
bkuhn
|
2204e09bfe39
|
8 years ago
|
|
Slightly increase scope: include payment requests
The project should really include outgoing payments along with it. Submitting an invoice for payment as an external party is really just a "base case" of a reimbursement request.
The only complication I can imagine this adds is allowing the general public to create an account on the system, or allow for anonymous submission, which might lead to spam concerns in deployment.
I believe these issues should be easily mitigated and will not drastically increase scope of the project.
As part of this actual change to the text, some wordsmithing and changes throughout to s/reimbursement/outgoing payments/ and other similar changes are made.
|
|
bkuhn
|
8018097f93b1
|
8 years ago
|
|
|
|
brett
|
1787ae44b2e9
|
8 years ago
|
|
|