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

Contenttype in 2 taxonomies not showing ordernumber when "has_sortorder: true" comes second #7693

Open
evertalbers opened this issue Oct 20, 2018 · 6 comments
Labels

Comments

@evertalbers
Copy link
Contributor

evertalbers commented Oct 20, 2018

I noticed that if a contenttype goes into 2 taxonomies and the second taxonomy is a
behaves_like: grouping
with a
has_sortorder: true
the sortorder number works OK behind the taxonomy tab in every single record but is not always shown in the contenttype overview page in the Bolt backend.

In a recent example (where projecttypes is the one with a sortorder, programlines is a category taxonomy) I noticed that changing
taxonomy: [ 'programlines', 'projecttypes' ]
into
taxonomy: [ 'projecttypes', 'programlines' ]
in contenttypes.yml solved this. So apparently, the taxonomy with sortorder should be mentioned as the first one.

If you see this as a bug, it should be solved in the code, if you regard it as a feature, it should be documented. :-)

@evertalbers
Copy link
Contributor Author

evertalbers commented Oct 20, 2018

screenshot_2018-10-20 overview projects streeff bolt cms

This is the ordernumber that may or may not be shown, in case the written decription is not entirely clear. (And don't you love those huge 4K monitor screenshots?)

@stale
Copy link

stale bot commented Dec 19, 2018

This issue has been automatically marked as stale because it has not had recent activity. Maybe this issue has been fixed in a recent release, or perhaps it is not affecting a lot of people?
It will be closed if no further activity occurs, because we like to keep the issue queue concise and actual.
If you think this issue is still relevant, please let us know. Especially if you’d like to help resolve the issue, either by helping us pinpointing the cause of a bug, or in implementing a fix or new feature.

@stale stale bot added the stale Stale issues & PRs flagged for closing label Dec 19, 2018
@evertalbers
Copy link
Contributor Author

Reviving. This may still deserve someone's attention, I think.

@stale stale bot removed the stale Stale issues & PRs flagged for closing label Dec 19, 2018
@psanchezg
Copy link
Contributor

Same problem here.

@stale
Copy link

stale bot commented Mar 26, 2019

This issue has been automatically marked as stale because it has not had recent activity. Maybe this issue has been fixed in a recent release, or perhaps it is not affecting a lot of people?
It will be closed if no further activity occurs, because we like to keep the issue queue concise and actual.
If you think this issue is still relevant, please let us know. Especially if you’d like to help resolve the issue, either by helping us pinpointing the cause of a bug, or in implementing a fix or new feature.

@stale stale bot added the stale Stale issues & PRs flagged for closing label Mar 26, 2019
@stale stale bot closed this as completed Apr 2, 2019
@bobdenotter
Copy link
Member

Let's keep this around.. Can't promise I'll have time to fix it anytime soon, but it does look like a bug.

@bobdenotter bobdenotter reopened this Apr 2, 2019
@stale stale bot removed the stale Stale issues & PRs flagged for closing label Apr 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants