@mbabker can you please assign this Issue to an 4.0-Project?

@icampus
I would prefer the solution, of the "Breadcrumbs". In my opinion its more clearer for a user to see in whitch Catergorys a user have rights and the tree view you are able to differentiate whitch Sub-Category belongs to a Parent category. Like its shown on the fourth Picture. And maybe the Categorys you don't have access should be score out.

@icampus
I would prefer the seccond solution. in my opinion its the cleanest one because it only shows the options you would have.
I think its helpfull for new users because they dont need to look for the right one. it can be usefull when you add a option for a advanced mode for showing all of parent category

@Dennissehrt

I think its helpfull for new users because they dont need to look for the right one. it can be usefull when you add a option for a advanced mode for showing all of parent category

Would you like this as a breadcrumb solution or showing the tree of the hierarchie the element is in?

@Schmidie64

Like its shown on the fourth Picture. And maybe the Categorys you don't have access should be score out.

So you would want to display both the tree of the hierarchie and the breadcrumbs at the bottom of every item? For my taste, this is a little much...

Considering the last screenshot, I personally would prefer a solution in which only the accessable items are displayed and they have the breadcrumbs thing at the bottom. I would also like to remove the dots at the front of any item to create a flat list as long as its not ordered by Ordering (for all cases where it's not ordered in a tree).

@eXsiLe95

you say:

I recently discovered some issues with the categories view for non-superusers. As it is right now (see screenshot underneath), it is very difficult spotting the categories you have access to. Therefore, I tried some things out which I could imagine for resolving this problem.

in the above context by categories the user has "access to" you mean categories that user can edit
you see

1. the view is already created (i mean the SQL query) according to view access levels !
2. and then inside the template the core.edit / core.edit.own ACL are used to display the editable categories

what you suggest would mean that core.edit / core.edit.own ACL for all categories is calculated before SQL query to get the categories and then category ids are used in the query to get the editable categories
For website with a lot of categories that would be heavy, especially if no caching is used and this recalculated on every page load

Now 2nd thing you propose to add full path
it would be nice to see it for all categories at once, but it will take some space

it is already possible for single category
... place your mouse over the category alias, and you will see the full path as a tip

maybe a button in the fillters area "Show paths" to toggle these on the fly

@ggppdk

in the above context by categories the user has "access to" you mean categories that user can edit
you see

This may got lost in translation. I did not mean the access levels that are already implemented. I meant these categories that a administrator user has access to (so canEdit, canEditOwn, ...)

For website with a lot of categories that would be heavy, especially if no caching is used and this recalculated on every page load

Yea, it is additional workload for the server, but it's not that much data that needs to be processed, I guess. I did not go that deep in the ACL thing, I'm not quite sure how much effort is needed to resolve this. I did think about work load a lot, but I think it might be wort the effort. In the end, it is always checked if the category is editable or not (so that it turns into a link or not), so it's not that much of additional work the server has to do.

What I mean is: With the pagination, you get 20 (for example) categories and then the server checks for every one of the categories if it is editable or not. For these purposes, we have to get more categories, because we can not know how many we actually can edit. But once we checked them and threw all these categories we don't need away, we do not need to check for access again because we already filtered them. The only effort which is additional would be to have to download all categories to check for accessability.

If there is any other possibility to get just the categories you have edit access to via SQL, please let me know. I could not think about any possibility about it yet...

place your mouse over the category alias, and you will see the full path as a tip

Good to know! So I don't need to do this myself, like I did for the screenshots.

@eXsiLe95

i understood that with "access" you meant "edit access"
that 's exactly why i answered about listing only editable categories

because you speak of implementation, it is relatively easy,
just calculate edit access on all categories and then use the found category IDs in the SQL query,
simple

but without caching the "editable" categories per user, it will add a couple or more seconds on every page view of category manager that is when you have a large number of categories, if you have 50 or even 100 categories then little / very performance difference

i think best option is not to make this default , maybe best is to add new filter "editable or viewable" categories ?

@ggppdk To check for edit access, I first need the list of all categories, so I don't need to create another SQL query to get only the necassary items. I just throw away all unnecassary.

But yea, a new filter would be good, I guess. Or a special caching table, but then it's too messy to go into core...

this can probably be closed as categories have the breadcrumbs suggested

closed as stated above.