Applying more than subcategory to the same content?

Edit: Applying more than one subcategory to the same content?

I just found out also that, the number of records show in Parent category is not representing the total number of records of its subcategory.

Did you try the "category select" templates under TYPE settings already? Maybe the "autocomplete" or "smart" might be helpful for you ...

1. We cannot apply more than one subcategory to the same content?

YOu can find this parameters in type submission slider

Allow multiple category select

Maximum number of multi categories

This will turn on multiple category select possibility.

1. We cannot apply more than one subcategory to the same content?

2. If we want to add content by going to sub category first and add/post, I still need to re-choose the category from the list because the category index on the list was set back to the first top category (not the one I choose before).

If it works this way, then it is a error. If you click POST ARTICLE link inside category, this category have to be selected by default in the form. There is small bug with SEF though. It will be fixed next release. But without SEF it should work.

1. We cannot apply more than one subcategory to the same content?

2. If we want to add content by going to sub category first and add/post, I still need to re-choose the category from the list because the category index on the list was set back to the first top category (not the one I choose before).

3. In ME resources, we can have a tree view for category list, can we have it here?

In advanced templates pack you have category index as tree view. You can also turn off category index and show category module with tree view template

Hi Sackgesicht,

"It is on purpose. As you can see in the template parameter, it states "Number of records in current category"". I'm sorry I'm not quite follow you, let say parent cat "A" has subcat "A1" and "A1" has 1 records, so on subcat "A1" and on parent cat "A" it should show records num = 1, that is what I understand with the function of "Number of records in current category". Otherwise, this parameter is not useful (Correct me if I was wrong).

OK, Sergey, will waiting for the next update.

Thank you.

that is what I understand with the function of "Number of records in current category"

Not exactly. What you want is "Number of records in current category and its subcategories". The current parameters works correct I think. It really shows number of records in the current category only without adding records from subcategories.

that is what I understand with the function of "Number of records in current category"

OK, Sergey, will waiting for the next update.

Next update on Thursday as usual weekly release.

Sergey,

Please check the pict below, this is what I understand how is the parameter should be works and why also some of them is not work. - Type 1.

When adding a content and we choose/highlight ONLY a subcategory, then the category field on table wc7uo_js_res_record was only contain subcategory.

• Type 2.

When adding a content and we choose/highlight a parent AND its subcategory, then the category field on table wc7uo_js_res_record was also contain parent category and subcategory

.

Both data entry method above create different result as what I've asked previously. I've found it after applying multi select parameter, (where still in single select, we cannot choose/highlight the parent category).

The second circle shows that the parent record num is representing subcategory num of records properly. (I just remember, I used to have the same problem like this in Resources).

I also found that the "Maximum number of multi categories" cannot working properly, I've set it with number of 3, but I still can choose and add more than 3 subcat from one parentcat and other 2 subcat from other parentcat.

This is where I have 2 records with multi subcategorries in category "Agent"

There are 2 methods to calculate records in category.

1. Records that saved directly in this category only

2. Records that saved in this category and all its subcategories (in all node/in all tree branch)

Right now calculation of records in category works like 1. only. It only shows number of records in this particular category without calculating records in subcategories.

And we cannot implement second method because it is TOOOOOO consuming. We better staty with complains of lack of this feature than with tons of complains that Cobalt is slow.

When adding a content and we choose/highlight ONLY a subcategory, then the category field on table wc7uo_js_res_record was only contain subcategory.

This column have nothing to do with calculations. It is only used to show categories of the record without additional query. The calculation use wc7uo_js_res_record_category table.

[

You do not need to select parent category. It is not good to make it just for correct counting. If you set Records Mode to Categories and subcategories when you are in Agent you will see also all records from Abrasive, Accounting, ..

Sergey,

I think we have missed understand here, and I dont know how to explain it :(

First of all, I absolutely agree with you about what you have explain with the second method, speed is my first priority concern and I don't want that second method too. This, we have the same perceptions.

So, I just want to get some explanation from you why using a different method of selecting category could create different method in storing category data and also create a different parent category [num recs] in category page.

OK, I will try your suggestion to set Records Mode to categories and subcategories on Parent Level, perhaps it could answer my question above,

And how about the "Maximum number of multi categories" ?

I've set it with number of 3, but I still can add more than 3

Sergey,

Do I need to change the Record Mode parameter for all category level (Parent and sub cat) to Records in categories and subcategories?

Because I've test it by changing at the parent level, and nothing changed.

Category stored in Category field still only store subcat, and at Parent level rec num is still not counting properly.

Perhaps you could test it on my server?

The Record Mode param does not affect counting.

I think we have missed understand here, and I dont know how to explain it

I have the same feeling. Like I just cannot understan you clearly.

I think we have missed understand here, and I dont know how to explain it

why using a different method of selecting category could create different method in storing category data and also create a different parent category [num recs] in category page.

When you store record it store categories

1. In record table in categories column. But that is not used anywhere only in templates to display categories of the record.

2. It store record in js_res_record_category. New record for every category. For example you place record in 3 categories. Then 3 records wil be created there. And this what we use to calculate. Then we see how many records in js_res_record_category against every category. So if you store article in Category A and it Subcategory B it will add number to both categories.

That is what I'm afraid of, Please apologies cause English is not my primary language.

I will try to explain it again with some example below:

I create a record under "Bank/Bank Central" category ("Bank Central" is a subcategory of "Bank").

I do that with only selecting "Bank Central" as category.

Let see how category being stored in table js_res_record

You can see that in Categories Field, is only store subcategory "Bank Central" and its ID.

Let see how the Category Main page looks like.

You can see that the records number at parent category ("Bank [0]") is not representing total of records number of its subcategory ("Bank Central [1]")

Now, I will edit the records and add the parent category ("Bank") in selection.

"Bank" and "Bank Central" are now selected.

Let see how category being stored in table js_res_record

Now, there are also "Bank" and "Bank Central" stored in categories field.

Let see how the Category Main page looks like after this changes.

The changes we've made, "Fix" (if I may say so) the records number counting at Parent level. Now, records number at parent category "Bank" can representing how many records on its subcategory (Bank Central)

Hope, we are in the same direction now.

What I would like you to help is, could you make it to automatically save the category value with both category level (parent and subcategory) like in the second example above, without the need to select its parents also in front?

I hope this could clear what I'm trying to say.

Sergey,

I just check table js_res_record_category, and what happened with js_res_record in example above is also happened with js_res_record_category.

if we choose only subcategory, then only subcategory is recorded in js_res_record_category

if we choose subcategory and parent category, then both category level were recorded js_res_record_category

Now, records number at parent category "Bank" can representing how many records on its subcategory (Bank Central)

Absolutely not. Now Bank category shows how many records in this particular category only despite its categories because you saved record in this category. It shows 1 because there is a record in this particular category not because there is a record in "Bank Central".

Now, records number at parent category "Bank" can representing how many records on its subcategory (Bank Central)

What I would like you to help is, could you make it to automatically save the category value with both category level (parent and subcategory) like in the second example above, without the need to select its parents also in front?

Unfortunately I cannot do this for the reason just to of calculation. What if someone do not need records there? What if that parent category is prohibited to submit in? And so many ifs there are.

What you want i a matter of calculation not storing records. Just the fact you saved record in "Bank central" have to add 1 to "Bank" category. You do not need to save it there. But we do not support this type of calculations. We only can count records in the category only without calculation of records in its node.

Well in that case,

Let's forget this, and let them just the way it is. So that means there will be some user who will posting the content by using the first method and some others use the second method (there is no protection to avoid this possibility), and number of records information at the Parent level will be mixed up and no use anymore.The category stored in both table will also not consistence, some record has a parent and some other not.

I just still don't get it why you still let user can choose to select subcategory with or without the parent on the category list. (At least you should protect it so we will have data consistency, only subcategory level stored in a table).

Or maybe we still not in the same direction here,.. :D

Or maybe we still not in the same direction here,..

This is what I do suspect :)

Or maybe we still not in the same direction here,..

I just still don't get it why you still let user can choose to select subcategory with or without the parent on the category list.

Cobalt is totally configurable and customisable in that regard. Lets put calculation aside. Then you can protect records not to be posted in parent category by simple setting allow submission to NO in the category parameter.

Or if you have a few tipes in section and you want one typу to be able to submit only one categories and their to other categories you can use type category limit parameter.

So conclusion is, you can totally control where you want which type to be submitted.

Or maybe we still not in the same direction here,..

I just still don't get it why you still let user can choose to select subcategory with or without the parent on the category list.

Let's forget this, and let them just the way it is. So that means there will be some user who will posting the content by using the first method and some others use the second method (there is no protection to avoid this possibility), and number of records information at the Parent level will be mixed up and no use anymore.The category stored in both table will also not consistence, some record has a parent and some other not.

I apologise for that. In fact current calculation mode is suitable only for Record Mode = Records in current category. In this mode it will give correct number because it will show exactly so many records as in category number like (2). But when we set Records mode to Categories and its subcategories, then calculation is wrong. It may show (0) n parent but show 100 from subcategories.

But till now we do not know how to sove this. this is long discussed and very complicated issue because of Cobalt features. The calculation query may be very very complicated.

OK Sergey,

Now, I think we are in the same perception :)

I've tried the first option, and That should be enough solution for now, because at Parent level, number of record is now disable while in subcategory still enable to see. It is also protect user for not selecting category at parent level.

My concerned is user can mixed up in selecting the category that could give wrong description about how many records stored at one Parent category (like you said " It may show (0) n parent but show 100 from subcategories"), but now with this solution this problem can be avoided.

And, I also want you to know that, I'm fully agree with you it is not worth to sacrifice already optimized query in order to enable records calculation at Parent level.

My other issue,

I also found that the "Maximum number of multi categories" cannot working properly, I've set it with number of 3, but I still can choose and add more than 3 subcat from one parentcat and other 2 subcat from other parentcat to be applied to the same records.

Perhaps you could do another "trick" for this.:D

Thank You Sergey,

I also found that the "Maximum number of multi categories" cannot working properly,

This is alreadt solved in 7.8874 we released yesterday (but forgot t upload file so we upload file today in 2 hours)