Implement organization limits

rixx commented

2026-02-02 14:36:32 +00:00

Member

closes #380, closes #384

Notable points:

We do not enforce organization limits in the OSB API – when a service is added to the OSB service list via the API, we do not check if this service is allowed per the list of service definitions in the limits profile
Once an organization is expired, we do not permit instance creation anymore, but users can still browse services and offerings. Imo this is better than not permitting it, but it's your call how locked-down an expired account should be.

closes #380, closes #384 Notable points: - We do not enforce organization limits in the OSB API – when a service is added to the OSB service list via the API, we do not check if this service is allowed per the list of service definitions in the limits profile - Once an organization is expired, we do not permit instance creation anymore, but users can still browse services and offerings. Imo this is better than not permitting it, but it's your call how locked-down an expired account should be.

rixx added 1 commit

2026-02-02 14:36:32 +00:00

Implement organization limits

Tests / test (push) Successful in 37s

Details

f79a974002

closes #380

tobru commented

2026-02-02 15:50:31 +00:00

Owner

We do not enforce organization limits in the OSB API – when a service is added to the OSB service list via the API, we do not check if this service is allowed per the list of service definitions in the limits profile

This is OK

Once an organization is expired, we do not permit instance creation anymore, but users can still browse services and offerings. Imo this is better than not permitting it, but it's your call how locked-down an expired account should be.

Yes, this makes sense this way.

Other things:

When an organization already hit the limit of maximum instances, the service creation fails after hitting "Create" with " Maximum service instances (1) reached.". We should even disable the "Get It" button when we've hit the limit, this gives a better user experience. Maybe show an information to the user that it's not possible to create new instances because of the limit reached.
The "Usage Limits" card on the organization details needs better alignment with other cards

> We do not enforce organization limits in the OSB API – when a service is added to the OSB service list via the API, we do not check if this service is allowed per the list of service definitions in the limits profile This is OK > Once an organization is expired, we do not permit instance creation anymore, but users can still browse services and offerings. Imo this is better than not permitting it, but it's your call how locked-down an expired account should be. Yes, this makes sense this way. Other things: * When an organization already hit the limit of maximum instances, the service creation fails after hitting "Create" with " Maximum service instances (1) reached.". We should even disable the "Get It" button when we've hit the limit, this gives a better user experience. Maybe show an information to the user that it's not possible to create new instances because of the limit reached. * The "Usage Limits" card on the organization details needs better alignment with other cards ![Screenshot_20260202_164939](/attachments/9f82fee4-dcb5-4d58-ab41-13651984b416)

Screenshot_20260202_164939.png

126 KiB

rixx added 5 commits

2026-02-02 17:01:29 +00:00

Improve organization properties bb45f8834e

Implement expiration reminders 8da243c821

Fix table alignment 021730bfe1

Code style b1fe0c8643

Disable service instance creation button when limit reached

Tests / test (push) Successful in 42s

Details

3697f512a1

rixx commented

2026-02-02 17:01:59 +00:00

Author

Member

When an organization already hit the limit of maximum instances, the service creation fails after hitting "Create" with " Maximum service instances (1) reached.". We should even disable the "Get It" button when we've hit the limit, this gives a better user experience. Maybe show an information to the user that it's not possible to create new instances because of the limit reached.

Done.

The "Usage Limits" card on the organization details needs better alignment with other cards

Done.

I now added the featureset described in #384: fully enforcing the validity limits + reminder sending (needs yet another cronjob). Notes on this implementation:

The reminder emails are plain text emails – HTML emails would be prettier, but would require some setup and design (HTML emails are notoriously hard to make look good in all or even most major email clients)
Who should receive the emails? Per the issue text, this should be all organization members, but we should probably limit this by roles?

> When an organization already hit the limit of maximum instances, the service creation fails after hitting "Create" with " Maximum service instances (1) reached.". We should even disable the "Get It" button when we've hit the limit, this gives a better user experience. Maybe show an information to the user that it's not possible to create new instances because of the limit reached. Done. > The "Usage Limits" card on the organization details needs better alignment with other cards Done. -------- I now added the featureset described in #384: fully enforcing the validity limits + reminder sending (needs yet another cronjob). Notes on this implementation: - The reminder emails are plain text emails – HTML emails would be prettier, but would require some setup and design (HTML emails are notoriously hard to make look good in all or even most major email clients) - Who should receive the emails? Per the issue text, this should be all organization members, but we should probably limit this by roles?

tobru commented

2026-02-03 07:20:11 +00:00

Owner

The reminder emails are plain text emails – HTML emails would be prettier, but would require some setup and design (HTML emails are notoriously hard to make look good in all or even most major email clients)

That's OK

Who should receive the emails? Per the issue text, this should be all organization members, but we should probably limit this by roles?

For now, all organization members are fine. We can refine this at a later stage if required.

reminder sending (needs yet another cronjob)

If I'm not mistaken, that would be similar to https://servala.app.codey.ch/servala/servala-portal/src/branch/main/deployment/kustomize/base/portal/cronjob.yaml, but with the send_expiration_reminders command? Would it make sense to implement this with Django 6 tasks and something like django-dbtasks? I'd create an issue for later for this then (out of scope of this PR).

Then:

In the "You have reached the maximum number of service instances (1) for this organization. Contact support to increase your limit." message, please link to /org/$org/support/
Same for "Contact us to extend"
This bar needs bit of alignment, the clock is misaligned

> The reminder emails are plain text emails – HTML emails would be prettier, but would require some setup and design (HTML emails are notoriously hard to make look good in all or even most major email clients) That's OK > Who should receive the emails? Per the issue text, this should be all organization members, but we should probably limit this by roles? For now, all organization members are fine. We can refine this at a later stage if required. > reminder sending (needs yet another cronjob) If I'm not mistaken, that would be similar to https://servala.app.codey.ch/servala/servala-portal/src/branch/main/deployment/kustomize/base/portal/cronjob.yaml, but with the `send_expiration_reminders` command? Would it make sense to implement this with Django 6 tasks and something like [django-dbtasks](https://github.com/imsweb/django-dbtasks?#periodic-tasks)? I'd create an issue for later for this then (out of scope of this PR). Then: * In the "You have reached the maximum number of service instances (1) for this organization. Contact support to increase your limit." message, please link to `/org/$org/support/` * Same for "Contact us to extend" * This bar needs bit of alignment, the clock is misaligned ![Screenshot_20260203_081832](/attachments/b7cfaa35-a616-48ac-a8cc-4a7e6e5cacd6)

Screenshot_20260203_081832.png

18 KiB

rixx commented

2026-02-03 09:52:55 +00:00

Author

Member

Would it make sense to implement this with Django 6 tasks and something like django-dbtasks?

Maybe! I haven't worked with the new Django tasks interface yet, and I think its strength and target will be in the realm of user-triggered tasks that are long running (e.g. generating download files etc) rather than scheduled tasks that should run in a fixed interval like crontabs. (You definitely can model one with the other; like with celery-cronjobs, but it always feels a bit awkward).

I do think that we'll want some sort of management around recurring tasks to avoid having a lot of cronjobs – instead probably a single frequently-running one that schedules/defers hourly tasks, daily tasks etc (or, even simpler and less prone to error until we need something more complex, possibly a manage.py daily_tasks, manage.py hourly_tasks). Worth discussing in a separate issue for sure.

In the "You have reached the maximum number of service instances (1) for this organization. Contact support to increase your limit." message, please link to /org/$org/support/
Same for "Contact us to extend"

Done, and also fixed the alignment, and made the call-to-support buttons look the same in alerts as in the top-level banners.

> Would it make sense to implement this with Django 6 tasks and something like django-dbtasks? Maybe! I haven't worked with the new Django tasks interface yet, and I think its strength and target will be in the realm of user-triggered tasks that are long running (e.g. generating download files etc) rather than scheduled tasks that should run in a fixed interval like crontabs. (You definitely can model one with the other; like with celery-cronjobs, but it always feels a bit awkward). I do think that we'll want some sort of management around recurring tasks to avoid having a lot of cronjobs – instead probably a single frequently-running one that schedules/defers hourly tasks, daily tasks etc (or, even simpler and less prone to error until we need something more complex, possibly a `manage.py daily_tasks`, `manage.py hourly_tasks`). Worth discussing in a separate issue for sure. > In the "You have reached the maximum number of service instances (1) for this organization. Contact support to increase your limit." message, please link to /org/$org/support/ > Same for "Contact us to extend" Done, and also fixed the alignment, and made the call-to-support buttons look the same in alerts as in the top-level banners.

rixx added 2 commits

2026-02-03 09:53:09 +00:00

Fix alignment and add support links b316a1b415

Improve look of support links in alerts

Tests / test (push) Successful in 38s

Details

89a524a7b5

rixx added 1 commit

2026-02-03 19:16:34 +00:00

Add user-based organization creation limits

Tests / test (push) Successful in 41s

Details