.AddCollection<Feature>(f => f.Id, "Feature", "Features", "A feature controlled by API security (like a role)", "icon-tools", "icon-folder", collectionConfig => collectionConfig
.HideFromTree()
.SetRepositoryType<FeatureKonstruktRepository>()
.SetNameProperty(f => f.Alias)
.SetFilter(f => f.Enabled)
.MakeReadOnly()
)
The collection is created to be allow me to use the entity picker in the editor of another collection. I'm using a custom repo, because my data layer is EF Core instead of NPoco. I don't think there is anything odd about my repository though.
When the entity picker loads and attempts to show set values, I get an exception thrown that appears to show that the filter I setup hasn't been correctly interpreted in the where expression (I assume reference to my f variable is wrong)
I can't think of anything I can change to fix this, so hence my guess that this is a bug. Many apologies if this is a false accusation.
Ok, I think you are right about the f param not getting converted properly. I've tried a quick update that I'm not sure if it will fix it or not (expression trees are a pain to figure out) but if you want to test it there should be a new 1.6.5-beta0003 on our unstable feed at https://nuget.outfield.digital/unstable/v3/index.json would be interesting to know if this does resolve it.
Sorry if I'm being a div, but if I upgrade to 1.6.5-beta003 it appears to break my backoffice.
I get the exception.
System.NullReferenceException, System.Private.CoreLib, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e: Object reference not set to an instance of an object.
at Konstrukt.Web.Controllers.Trees.KonstruktTreeController.get_RootNodeDisplayName()
at Umbraco.Cms.Web.BackOffice.Trees.TreeControllerBase.CreateRootNode(FormCollection queryStrings)
...
at Umbraco.Cms.Web.BackOffice.Trees.ApplicationTreeController.GetApplicationTrees(String application, String tree, FormCollection queryStrings, TreeUse use)
at Umbraco.Cms.Web.BackOffice.Controllers.SectionController.GetSections()
My only action was to update with nuget, and reverting the change fixes things.
Ok, no worries. Just means it's going to take a bit more digging and trying to setup a replication environment. Was hoping I could just spot it and throw a fix out quickly.
I don't suppose this is easy enough to break out into a simplified solution with just that example in is it? It would be good to have your exact use case as a test environment but I need to ensure I don't have access to any other data / content.
Possible bug: Collection with filter
I have a collection with a filter.
The collection is created to be allow me to use the entity picker in the editor of another collection. I'm using a custom repo, because my data layer is EF Core instead of NPoco. I don't think there is anything odd about my repository though.
When the entity picker loads and attempts to show set values, I get an exception thrown that appears to show that the filter I setup hasn't been correctly interpreted in the where expression (I assume reference to my
f
variable is wrong)I can't think of anything I can change to fix this, so hence my guess that this is a bug. Many apologies if this is a false accusation.
My workaround is very straightforward, which is to move the
Where()
to the repo rather than the configurator.Does it work if you change your expression to
f.Enabled == true
instead?Good thinking, but unfortunately not. I get the same result.
Ok, I think you are right about the
f
param not getting converted properly. I've tried a quick update that I'm not sure if it will fix it or not (expression trees are a pain to figure out) but if you want to test it there should be a new 1.6.5-beta0003 on our unstable feed at https://nuget.outfield.digital/unstable/v3/index.json would be interesting to know if this does resolve it.Sorry if I'm being a div, but if I upgrade to 1.6.5-beta003 it appears to break my backoffice.
I get the exception.
My only action was to update with nuget, and reverting the change fixes things.
Let me take a look. That build contains some other bug fixes so one is probably not quite right
Ok, there is a beta0004 on there now if you want to try that one.
No dice. Sorry.
Ok, no worries. Just means it's going to take a bit more digging and trying to setup a replication environment. Was hoping I could just spot it and throw a fix out quickly.
I don't suppose this is easy enough to break out into a simplified solution with just that example in is it? It would be good to have your exact use case as a test environment but I need to ensure I don't have access to any other data / content.
Actually, there is a beta0006 on there now which I "THINK" might resolve it.
I was just packing up the app to send over to you, but you beat me to it! I can confirm that this is fixed in 1.6.5-beta0006.
Well done. Expressions make my brain hurt.
mine too 😁
Thats awesome. Thank you for testing and sorry to waste your time packing your solution up 👍
is working on a reply...