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

Add support for getting/setting default swimlane on a Project #166

Closed
psybers opened this issue Dec 29, 2023 · 0 comments · Fixed by #167
Closed

Add support for getting/setting default swimlane on a Project #166

psybers opened this issue Dec 29, 2023 · 0 comments · Fixed by #167

Comments

@psybers
Copy link
Contributor

psybers commented Dec 29, 2023

Description

This is related to #162. The support for swimlanes, as implemented in #164 missed the ability to get/set the project's default swimlane. In the GUI, this is a little star to indicate which swimlane new stories will be assigned to by default.

Use cases

Users may wish to mark which swimlane is currently the default in the project, so that any new user stories default to being added to that particular swimlane.

In one of my projects, I have swimlanes based on weeks (in a semester). I have a script that runs in a cron each week and updates the default swimlane to the current week. This saves having to select the swimlane when manually adding new stories to the project via the UI.

Proposed Solution

Since default_swimlane is already a property of a Project, we just need to add it to the list of allowed params. Then you can read/write the property as normal:

print(project.default_swimlane) # prints a swimlane ID

# changes the default swimlane, based on a swimlane ID
project.default_swimlane = project.list_swimlanes()[0].id
project.update()

Alternate Proposals

It appears nothing makes use of patch() currently? This feature seems like it would be much better to just PATCH the single value instead of doing a full PUT of all attributes on the Project.

I think the proposed solution is currently the best. But I would recommend another, separate, PR that maybe caches the object's values and then when update() is called detects which values changed and performs a PATCH on just those values.

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

Successfully merging a pull request may close this issue.

1 participant