Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow site-level control of how Resources ordered within an Allocation #335

Merged
merged 1 commit into from
Jan 11, 2022

Conversation

payerle
Copy link
Contributor

@payerle payerle commented Nov 10, 2021

See #334
This modifies the methods get_resources_as_string() and get_parent_resource() of the Allocation class, specifically it modifies how those routines order the resources attached to the allocation for display, etc.

The modifications cause both of these methods to order the resources by
the value of the setting ALLOCATION_RESOURCE_ORDERING. This should be a
list ref of arguments to pass to the Django QuerySet order_by() method. The
default value is [ '-is_allocatable', 'name' ], which means that Resources
which are allocatable (is_allocatable==Yes) will come before non-allocatable
resources, and among Resources of the same allocatability, the Resources will
be ordered by name.

This should result in get_parent_resource returning the same resource as
before (as it previously used the default 'name' ordering from Resource and
then filtered/selected only allocatable Resources when the Allocation was
associated with more than one Resource); except in the abnormal case wherein
an Allocation has more than one Resource and none are allocatable (the old
behavior returned None, which could result in various issues; the new behavior
is to return one of the non-allocatable Resources).

The result of get_resources_as_string may change, as previously it only
ordered by '-is_allocatable', so the ordering of allocatable resources is
presumably up to the database backend (???). The new behavior is consistent
with get_parent_resource(), i.e. the Resource returned by get_parent_resource()
will now always be the first Resource listed in get_resources_as_string().

Added documentation for ALLOCATION_RESOURCE_ORDERING under config page.

This modifies the methods get_resources_as_string() and get_parent_resource() of the Allocation class, specifically it modifies how those routines order the resources attached to the allocation for display, etc.

The modifications cause both of these methods to order the resources by
the value of the setting ALLOCATION_RESOURCE_ORDERING.  This should be a
list ref of arguments to pass to the Django QuerySet order_by() method.  The
default value is [ '-is_allocatable', 'name' ], which means that Resources
which are allocatable (is_allocatable==Yes) will come before non-allocatable
resources, and among Resources of the same allocatability, the Resources will
be ordered by name.

This should result in get_parent_resource returning the same resource as
before (as it previously used the default 'name' ordering from Resource and
then filtered/selected only allocatable Resources when the Allocation was
associated with more than one Resource); except in the abnormal case wherein
an Allocation has more than one Resource and none are allocatable (the old
behavior returned None, which could result in various issues; the new behavior
is to return one of the non-allocatable Resources).

The result of get_resources_as_string may change, as previously it only
ordered by '-is_allocatable', so the ordering of allocatable resources is
presumably up to the database backend (???).  The new behavior is consistent
with get_parent_resource(), i.e. the Resource returned by get_parent_resource()
will now always be the first Resource listed in get_resources_as_string().

Added documentation for ALLOCATION_RESOURCE_ORDERING under config page.
@aebruno aebruno merged commit 0c65d1e into ubccr:master Jan 11, 2022
@aebruno
Copy link
Member

aebruno commented Jan 11, 2022

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants