* Bill types added in Bill and Project Model, Implemented in BillForm
* import and export bill feature updated with bill type, tests modified to reflect the behavior
* eliminating unnecessary bill type
* typo fixed, test cases fixed for the current bill types
* button added
* settle button added
* new changes
* test cases added
* bchen-reimbursement
* tests for different bill types
* test cases fixed
* fixed reimbursement test case
* Replaced assertEqual with assert
* Fixed missing bill_type in unit tests
* Removed commented code
* Reverted unnecessary string edit
* Changed bill_type to an Enum
* Added test checking correct bill_type validation
* Fixed billtype displaying in all caps
* Removed 'Transfer' bill type
* Added migration rule and set default bill_type in alembic
* bill_type is now an optional parameter in the BillForm
* Use enum name instead of value as SQL server_default
SQLAlchemy uses the Enum names in the database, as the values could be
generic python objects.
https://docs.sqlalchemy.org/en/20/core/type_basics.html#sqlalchemy.types.Enum
* Removed bill type from the Bills html table
* Replaced string bill type with enum
* Made "Settlement" translatable
* Manually handle the new Enum creation
Alembic does not handle postgres Enums correctly, so we need to manually
generate the new enum type.
See https://github.com/sqlalchemy/alembic/issues/278
---------
Co-authored-by: Ruitao Li <ruital@andrew.cmu.edu>
Co-authored-by: MelodyZhangYiqun <98992024+MelodyZhangYiqun@users.noreply.github.com>
Co-authored-by: Ruitao Li <49292515+FlowingCloudRTL@users.noreply.github.com>
Co-authored-by: MelodyZhangYiqun <yiqunz@andrew.cmu.edu>
Co-authored-by: Brandan Chen <bychen@andrew.cmu.edu>
Co-authored-by: Emilie Zhou <54161959+ez157@users.noreply.github.com>
Co-authored-by: Tom <tom.roussel@esat.kuleuven.be>
Adds two configuration parameters that are passed to
generate_password_hash:
- PASSWORD_HASH_METHOD
- PASSWORD_HASH_SALT_LENGTH
The unit tests use high-speed low-security values and
gain 50% speed.
F-strings are a bad idea for translations, because they cause Babel to
crash when collecting strings to translate:
https://github.com/python-babel/babel/issues/715
But even if we replaced f-strings with new-style string interpolation such
as `_("{foo}").format(foo=foo)`, it's still a bad idea, because a wrong
translation can crash Ihatemoney at runtime with a KeyError.
Instead, we must really use old-style python formatting since they are
well supported in Babel. Wrong translations that mess with string
interpolations will cause Babel to give an error when compiling
translation files, which is exactly what we want.
This was broken due to changes introduced to make project deletion more
secure. Rather than doing some complicated if branches, I decided this
dashboard stuff is probably better handled with separate routes instead.
So I've reintroduced a way to delete the projects without specifying the
project code (otherwise it's not possible for admins to do it).
* get weight sum along with bills to scale
otherwise, we need to get the weight sum for each displayed bill.
Here, we are much more scalable
* add test
* format
* remove unused import
* oops, restore pagination to 100
* add comments
* format
* rename method to make it clearer
And also, make it static, since it doesn't rely on instance.
* improve comments and naming
* improve naming
* missing article
* Change the way we import datetime
This makes it easier to use datetime.date later.
* Display monthly statistics for the range of months where the project was active
Currently, we display a hard-coded "one year" range of monthly statistics
starting from today. This generally is not the intended behaviour: for
instance, on an archived project, the bills might all be older than one
year, so the table only displays months without any operation.
Instead, display all months between the first and last bills. There might
be empty months in the middle, but that's intended, because we want all
months to be consecutive.
If there are no bills, simply display an empty table.
Co-authored-by: Baptiste Jonglez <git@bitsofnetworks.org>
* /healthcheck endpoint usefull for monitoring, ci test also uses this
* customizable PORT with environment variable
* customizable PUID/PGID, reduce attack surface and allow better integration in rootless environments
* size optimization
* update to python 3.10
* add postgresql compatibility
* PUID/PGID default as root to not break current user environments
* Do not require a captcha when using the API
This was trickier than expected, due to some side effects : when the
captcha is set to `True` via configuration, it doesn't change the
behavior directly of the ProjectForm class, but does so only when the
project form is used in the `web.py` module.
So, when just using the API (and not using the web.py module, for
instance during tests — manual or functional), no problem was shown,
and everything was working properly.
But at soon as somebody sees the "/" endpoint, the captcha was
required, by both the API and the `web.py` module.
This fixes it by adding a way to bypass the captcha with a new
`bypass_captcha` property on the form.
Prior to this commit, things were done by activating or deactivating a
"captcha" property on the class on-the-fly, which caused side-effects.
This is now using subclasses, which makes the code simpler to
understand, and less prone to side-effects.
Thanks @zorun for the idea.
Fix#780
This a breaking change, the API for authentication is different, as it now requires `project_id`. Token is generated with only the project_id (so it's shorter than before), and signature is done by mixing password with secret key. Thus, it expires on every project code change.
This is the same idea as deleting a project: deleting history is also a
major destructive action. We reuse the same form as for project deletion
to ask for the private code and provide CSRF validation.
Co-authored-by: Alexis Métaireau <alexis@notmyidea.org>
Currency switching is both simpler and less powerful. This was done primarily for users, to have a clear and logical understanding, but the code is also simpler. The main change is that it is now forbidden to switch a project to "no currency" if bills don't share the same currency.
Also, tests assume that projects are created without currency, as in the web UI.
In one case, we were not catching a family of possible exceptions
(socket.error), and in the two other cases there was no error handling at
all. Sending emails can easily fail if no email server is configured, so
it is really necessary to handle these errors instead of crashing with a
HTTP 500 error.
Refactor email sending code and add proper error handling.
Show alert messages that tell the user if an email was sent or if there
was an error.
When sending a password reminder email or inviting people by email, we
don't proceed to the next step in case of error, because sending emails is
the whole point of these actions.