Skip to content

Project tags can not be updated using the API #7354

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.

Sign up for GitHub

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

Jump to bottom
Closed
nijel opened this issue Aug 3, 2020 · 5 comments
Closed

Project tags can not be updated using the API #7354

nijel opened this issue Aug 3, 2020 · 5 comments
Labels
Accepted Accepted issue on our roadmap Good First Issue Good for new contributors Improvement Minor improvement to code Sprintable Small enough to sprint on

Comments

@nijel
Copy link
Contributor

nijel commented Aug 3, 2020

Details

Expected Result

The projects API does include project tags, but it's not possible to update it or set when creating new projects.

Actual Result

When including tags in the request, it gets silently ignored.

Another source of confusion might be that ProjectCreateSerializer and ProjectCreateSerializer are different - is there any reason to allow less fields in project creating than later in updating it?
nijel added a commit to WeblateOrg/weblate that referenced this issue Aug 3, 2020
@nijel
Scripts: Add script to create translation projects on readthedocs.org
35198cd 
It does basic setup, but still it needs manual tweaking:

* It can not update tags, see readthedocs/readthedocs.org#7354
* It can not link translation projects to main one, see readthedocs/readthedocs.org#7351
* Automation rules on newly created projects are missing, see readthedocs/readthedocs.org#7350
@stsewd
Copy link
Member

stsewd commented Aug 3, 2020

Another source of confusion might be that ProjectCreateSerializer and ProjectCreateSerializer are different - is there any reason to allow less fields in project creating than later in updating it

I think that was done to mimic the import page, but if we don't have a strong reason, I think it makes sense to allow all the fields

@stsewd stsewd added Improvement Minor improvement to code Needed: design decision A core team decision is required labels Aug 3, 2020
@humitos
Copy link
Member

humitos commented Mar 15, 2021

I think it makes sense to allow all the fields

I'm fine adding support to change most (or all) the fields at this point.

@humitos humitos added Accepted Accepted issue on our roadmap Good First Issue Good for new contributors Sprintable Small enough to sprint on and removed Needed: design decision A core team decision is required labels Mar 15, 2021
@SyedMa3
Copy link
Contributor

SyedMa3 commented Aug 7, 2022

@humitos Is this issue still open?

@humitos
Copy link
Member

humitos commented Aug 8, 2022

@SyedMa3 yes

@SyedMa3 SyedMa3 mentioned this issue Aug 17, 2022
Merged
@benjaoming
Copy link
Contributor

Fixed in #9513 - thanks to @SyedMa3 for this contribution 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Accepted Accepted issue on our roadmap Good First Issue Good for new contributors Improvement Minor improvement to code Sprintable Small enough to sprint on
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@nijel @humitos @benjaoming @stsewd @SyedMa3