getting rid of app_url because it was a strange wrapper around
request.host_url & doesn't seem to provide any value except to confuse
the code. eliminated it.
in the process touched up some comments & email templates.
modified: make_post_sell/lib/mail.py
modified: make_post_sell/lib/mail_messages.py
modified: make_post_sell/models/product.py
modified: make_post_sell/models/shop.py
modified: make_post_sell/request_methods.py
modified: make_post_sell/templates/base.j2
modified: make_post_sell/templates/product_edit.j2
shop user roles: owners, editors, members
shop user roles: owners, editors, members
Huge pull requests.
In this PR we implement role based authorization by extending the "user shop" table to include a new field for tracking a rudimentary role id integer.
For now the integers are from 0,1,2
0 == owner (root) 1 == editor (virtual assistant) 2 == member (viewer)
For now the member role doesn't provide any additional behavior but could be added to a future enhancement.
We have now separated out privileged views into requiring the user to be part of the owner role or editor role depending on the route.
We have created a new route called shop_users & it works for adding or removing new users into the active shop. As such for example, only users with owner access may access the new shop_users view and as such only they can add or remove users from the shop.
shop user roles: owners, editors, members
Huge pull requests.
In this PR we implement role based authorization by extending the "user shop" table to include a new field for tracking a rudimentary role id integer.
For now the integers are from 0,1,2
0 == owner (root) 1 == editor (virtual assistant) 2 == member (viewer)
For now the member role doesn't provide any additional behavior but could be added to a future enhancement.
We have now separated out privileged views into requiring the user to be part of the owner role or editor role depending on the route.
We have created a new route called shop_users & it works for adding or removing new users into the active shop. As such for example, only users with owner access may access the new shop_users view and as such only they can add or remove users from the shop.
I do think we need some mechanism to throttle the speed of attempts
to prevent brute force. This would be a separate PR.
modified: models/user.py
modified: templates/join-or-log-in.j2
modified: templates/verification-challenge.j2
modified: views/authentication.py
