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

Creating Document type collection beneath DocType doesn't set parent correctly #4473

Closed
KevinJump opened this issue Feb 7, 2019 · 5 comments
Labels
status/stale Marked as stale due to inactivity type/bug

Comments

@KevinJump
Copy link
Contributor

Creating a Document Type Collection beneath another DocumentType doesn't create the parent composition relationship correctly. (v7.13.0 -> 7.13.2)

Reproduction

  • Create a Document Type (e.g. MasterType)
  • Create a Document Type Collection beneath this (e.g Parent, Child)
  • Create a property on the master,
  • then view the parent or child, neither will show the inherited property from the MasterType.

Expected : You should be able to see master properties inherited in these children.

Bug summary

When a DocType is created in a collection, the parentId is set, but the parent is not also added to the list of compositions for the doctype they are created under.

Creating a single Document Type under a parent does add that parent type to the list of compositions and you do see inherited properties from that parent in the newly created document type.

@jveer
Copy link

jveer commented Feb 27, 2019

This bug is still occurring with Umbraco 8.0.0, you are also unable to inherited the properties manually through compositions.

Expected Result

image


Actual Result

image

@umbrabot
Copy link

umbrabot commented Jan 9, 2021

Hiya @KevinJump,

Just wanted to let you know that we noticed that this issue got a bit stale and might not be relevant any more.

We will close this issue for now but we're happy to open it up again if you think it's still relevant (for example: it's a feature request that's not yet implemented, or it's a bug that's not yet been fixed).

To open it this issue up again, you can write @umbrabot still relevant in a new comment as the first line. It would be super helpful for us if on the next line you could let us know why you think it's still relevant.

For example:

@umbrabot still relevant
This bug can still be reproduced in version x.y.z

This will reopen the issue in the next few hours.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

@umbrabot umbrabot added the status/stale Marked as stale due to inactivity label Jan 9, 2021
@umbrabot umbrabot closed this as completed Jan 9, 2021
@mariamus
Copy link

@umbrabot still relevant
This bug can still be reproduced in version 8.2.1

@mariamus
Copy link

It seems like this issue occurs because the parent/child relationship is not added in the database.
check your database with:

SELECT cmsContentType2ContentType.parentContentTypeId, cmsContentType2ContentType.childContentTypeId, cmsContentType.alias FROM cmsContentType2ContentType INNER JOIN cmsContentType ON cmsContentType2ContentType.childContentTypeId=cmsContentType.nodeId

You can also add a WHERE clause that only shows the parent type you need.

Run the above query in the database and check if the binding exists. if it does not, find the nodeId of the broken doc type and the parent you need in the cmsContentType table and insert them with:

insert into cmsContentType2ContentType (parentContentTypeId, childContentTypeId) values (value1, value2)
where value1 if your parent and value 2 is your child.

This should make your composition available. it might not show up right away, but build and remember to check your child doctype's config file. The parent key and composition should show up then.

@nul800sebastiaan
Copy link
Member

Thanks @mariamus! v8.2.1 is pretty old now, I just tried the reproduction steps in 8.18 and everything seems to work as expected. I'll close this again as it looks like it's been fixed along the way.

@nul800sebastiaan nul800sebastiaan closed this as not planned Won't fix, can't repro, duplicate, stale Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status/stale Marked as stale due to inactivity type/bug
Projects
None yet
Development

No branches or pull requests

7 participants