Department Browser Needs SERIOUS work
Hello Steve,
its a known issue of the department widget :(. When a product is added to a children it is NOT counted as part(or added) to its the parent :( this is why the count is not updated and even more .. when you click the parent department it doesn't show the products.
However the fix is very easy from your side.. you just need to add each product not only to the child department but ALSO to its parent. Then everything will work and you can use a hierarchical departments without our fix.
Checkout the attached screenshots:
The product is added only to dep1child without dep1 but it is added both to dep2 and dep2child which makes the second case working correctly.
I hope this helps.
With 800 products, that's not "easy" :)
...also seems very hacky...that's a big burden to put on the client, or myself to have to script it all out to update every product with all the parent taxons, no?
Hello Steve,
yes I agree its not easy indeed :) but at least its possible. :) 800 products are not like 250 000:)
Also this is a old known limitation of the departments control it was like that till the beginning of the widget and the ecommerce module
Usually this limitation of the department control should be found during development phase and the products for live/production site should be prepared taking this limitation under consideration. Also it is good if this is said to every content/product manager in the user guide so he is aware of that when adding products, because running an upgrade script each day or week ...
Alternative would be to extend DepartmentControl but currently almost everything inside this control is internal and to make it work correctly will basically mean recreating the whole population of the data which is not easy task.
Keep in mind the department control is not fixed for so long time because of a reason.
The reason is that knowing this limitation it is very easy to write in the user guide to the clients/ content managers how to fill the data.
However the alternative to take each department count to count each of its children departments and each of their childs and each of their childs and making this on every request, assuming it is used on page without output cache, will make the control extremely slow.
It is limitation yes but you get a better performance long term at the end. Also it gives you the flexibility to "hide" some parent departments if you want and to make a custom landing page ones his parent department is clicked which shows the child departments (even the ones which have 0 products) in a nice custom grid view for example with a nice brand banner on top and etc but then to show their child departments correctly with counts :)
It wouldn't be slow at all, taxon statistics are stored flat, should be dynamically calculating anything...aside from a sum of parent counts.
At the very *least* it should be an option (enabled by default) :)
Steve
its in our backlog :)) hopefully will be made soon.
You can send this to a public issue tracker system if it is not already there and vote for it :) I would vote myself as well :) . I agree that it should be an option :)
Still ... for now... :) you know what should be done ;)
Regards,
Nayden
You (or anyone there) don't happen to have an update script that would link these all together would you?
Hi Steve,
Currently we do not have an upgrade script on SQL level which updates that.
however it is very easy to update them using the API.
in short the steps:
//get all master products
//get all departments in the custom field "Department" which contains a list of ids
//get each department
//check if the department have parent if yes assign it to the product and keep checking his parents and so on.
//save changes
//publish
private
void
UpgradeProductsToContainsParentDepartments()
var catManager = CatalogManager.GetManager();
var taxManager = TaxonomyManager.GetManager();
var products = catManager.GetProducts().Where(p => p.Status == ContentLifecycleStatus.Master);
foreach
(var p
in
products)
var departmentIds = product.FieldValue<TrackedList<Guid>>(
"Department"
);
boolean hasParentDepForAdd =
false
;
foreach
(var depId
in
departmentIds)
var taxon = taxManager.GetTaxon(depId);
if
(taxon.Parent !=
null
)
hasParentDepForAdd =
true
;
AssignParentTaxonToProduct(p,taxon.Parent);
if
(hasParentDepForAdd)
catManager.SaveChanges();
//publish
var contextBag =
new
Dictionary<
string
,
string
>();
contextBag.Add(
"ContentType"
, p.GetType().FullName);
WorkflowManager.MessageWorkflow(
p.Id
p.GetType(),
providerName,
"Publish"
,
false
,
contextBag);
private
void
AssignParentTaxonToProduct(Product product, ITaxon taxon)
product.Organizer.Add(
"Departments"
,taxon);
if
(taxon.Parent !=
null
)
AssignParentTaxonToProduct(product,taxon.Parent);
YOU ARE AWESOME!
Sorry yeah when I say 'script' in the context of Sitefinity I meant api code :)
I wouldn't dare even touch the db there's so much going on ;)
Hi Steve,
I am glad I was able to help.
Yes, writing this code in SQL statements will be really difficult.
Regards,
Nayden Gochev
Telerik
Okay...I encountered a scenario where this all just falls apart and shouldn't be used :/
When we need "Related" content...the problem is that you're part of the ENTIRE tree...example
- Food
- Bread
- White
- Brown
- Vegetables
- Green
So you're on the detail page of a type of White bread...you want to show 5 items "related" to it. But querying the linked taxa gives you all 3...so you can't just query back to get ACTUAL related things because you'll end up with unrelated stuff which might not even be bread. Because Vegetables are also techically tagged with "food" right.
So there'd have to be an extra query to like find the lowest child and only query based on that which removes the ability to have a selected taxon which ISN'T a child....this is the method I had to take.
Know what I mean?
Hi Steve,
Thank you for the feedback. I have passed it along to the Ecommerce team.
Regards,
Atanas Valchev
Telerik