Create an endpoint in the Admin Api to be able to update a user’s limits
for all existing and new projects. Also added a GET endpoint to return
user's limits.
Fixes: https://github.com/storj/storj/issues/5395
Change-Id: I2c093dc08ebf79a4318391e63a37da4d2b403547
Returns only user's own projects when we hit GET user endpoint.
Fix for this issue
https://github.com/storj/storj/issues/4820
Change-Id: I546268fa3e5983a72f11f998803da5455c0035b4
The users.Update method in the satellitedb package takes a console.User
as an argument. It reads some of the fields on this struct and assigns
the value to dbx.User_Update_Fields. However, you cannot optionally
update only some of the fields. They all will always be updated. This means
that if you only want to update FullName, you still need to read the
user info from the DB to avoid updating the rest of the fields to zero.
This is not good because concurrent updates can overwrite each other.
This change introduces a new struct type, UpdateUserRequest, which
contains pointers for all the fields that are updated by satellite db
users.Update. Now the update method will check if a field is nil before
assigning the value to be updated in the db, so you only need to set the
field you want updated. For nullable columns, the respective field is a
double pointer. This allows us to update a column to NULL if the outer
pointer is not nil, but the inner pointer is.
Change-Id: I27f842d283c2711e24d51dcab622e57eeb9157f1
We have a couple of support tickets so far that require us to
disable the mfa on accounts. Since we currently had no other
way than doing a SQL War Crime, it makes sense to add it to the
admin API.
Change-Id: Ib16735c1961380b04345a3495d4eebee5fa0bc41
An older change plummed the full console config as subconfig of
the admin api configuration in. This bloated the generated satellite
configuration unnecessarily while also allow for confusion/mistakes.
Change-Id: Icf49cc1f147711e37e85f6eac1143fab8ddf1659
Extended user update query so prod owner can change user's paid tier status, bandwidth, storage and segment limits.
Change-Id: I82768afd1e50f653a50f7020310ce1e91578d746
Users signing up through a url containing a promo code will have that code applied to their stripe account instead of the free tier coupon.
Change-Id: I071041b0934648ef3f5bdb05b6ec97c400f89ae4
To allow for changing limits for new users, while leaving existing users limits as they are, we must store the project limits for each user. We currently store the limit for the number of projects a user can create in the user DB table. This change would also store the project bandwidth and storage limits in the same table.
Change-Id: If8d79b39de020b969f3445ef2fcc370e51d706c6
3b751a35c Removed our old coupon functionality, and slightly reworked
the invoice List() function in the stripecoinpayments package.
It turns out, this is causing some issues when trying to delete users.
This change keeps the new functionality, which is used in the satellite
UI, but under a new name, ListWithDiscounts()
Change-Id: I6a62a1de480e09d005dd22d75aa1e024fd2ed3a0
Removes database tables and functionality related to our custom
coupon implementation because it has been superseded by the Stripe
coupon and promo code system. Requires implementations of the
payments Invoices interface to return coupon usages along with
invoices.
Change-Id: Iac52d2ff64afca8cc4dbb2d1f20e6ad4b39ddfde
* Add test cases to verify that all the endpoint that target a specific
entity respond 404 status code when the entity isn't found.
* Fix the endpoints that target a specific entity which responded a 500
status code response when the entity didn't exist to respond with 404
status code.
Additionally:
* Simplify some tests using an existing test helper function.
* Rename test functions to start with the entity name (e.g. Project,
User, etc.) for easing to run a set of test with the `-run` Go test
flag.
Change-Id: I82aad92e429207b72932ad4b79c08db6b486a19a
Validates the new user data, through `Validate` method, on "create user"
endpoint earlier and remove specific checks of data that is already
validated by the `Validate` method.
Change-Id: I6b8f91c0b706f0c8316173c491e25c4858172640
A previous commit added a helper function for sending JSON data back to
the client.
This commit makes use of it for homogenizing the current implementation.
It also renames the existing helper message to send JSON errors to
starts with "send" because the new helper starts with it and they
helpers are clearer with their name starting with it.
Change-Id: I53ee0b4ca33d677a8ccd366c9ba6d73f4f472247
Currently we do not allow anything other than the "paid" status for invoices when
trying to delete a user. However there can be a couple of other states that are
still fine to accept during deletion of a user. This change reverses the order to
check for the status that we do not want to allow.
Change-Id: I78d85af6438015c55100fa201ccffc731c91de1c
This change adds the capabilities to adjust the users project limit via the Admin API.
Adds a test for the new added function of the API and updates the existing tests.
It renames the json field on the user struct to be more consistent.
Change-Id: I9018acd80dae0af68d1d50526f20987132c654f3
To prevent creating multiple users with the same email via API, we should check for an existing user with given email.
Change-Id: Ie35b85c4f94a7ca72d42951dab8ff475d7f0dd7c
Currently a customer created via the IP does not get an payment account until he signs in.
That causes issues if the account should be deleted again.
Change-Id: I393c8f301e426301bb713c423d6ce011138d4ae4