Configurate listview per member type

[bjarnef]

Based on Umbraco v8.12.2 it is currently not possible to create a listview configuration per member type similar to document types.
When having multiple member types some of these might have properties which is useful to display in listview, but not available on other member types.

[nul800sebastiaan]

That's correct, members are a little special and I believe there's a technical limitation to turning a member type into a custom list view, I'll have to check.

In the mean time I you could any listview datatype you want to member types and the might be the way to go.

[bjarnef]

@nul800sebastiaan yes, I could create a listview and add this to the member type, but it really doesn't make sense since when viewing it doesn't have any children.

So it would look like this:

If adding a property using listview datatype to Content and Media, you would add this to the parent content type, so an archive content type like e.g. "Folder" in media section.

For members we don't have any member type for this - only the child item itself, like "Member" member type or "Brand" and "Staff" member types in this case.

[umbrabot]

Hiya @bjarnef,

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 🤖 🙂

[bjarnef]

@umbrabot still relevant

[nielslyngsoe]

Hi @bjarnef I would like to know more about your case, to understand how such feature would make sense for a future version?

Causeyour perspective could make us consider a different structure for the Members section. So please share the use case and then I will be aware about this for future versions. (And share it despite I close this issue, thanks!)

Thanks in advance, and until then I will close the issue cause it does not make sense from v.14+ as Members cannot be nested/parented/ or put in folders. And we will not put effort into changing this for v.13 or older versions. :-)

[bjarnef]

@nielslyngsoe a few things why I think this makes sense.

• Consistency: Document, media and member types are more aligned than in past. Nowadays they have many of the same features. Pproperties, tabs, groups, composition, copy, use of same datatypes/property editors. Member types still lack when using more complex datatypes like Block List and Block Grid. A single block or basic block on member would make sense though. Another missing feature is folder (entity container) for member types. I have submitted a PR for that part though. Member type container in management API #16914 Initially for backend PR and the one for the old backoffice was rejected.

• I have worked on previous projects where we had multiple member types with different properties, but since members use same listview configuration, we couldn't differentiate the listview configuration per member type as we can for content and media.

[bjarnef]

Ideally the listview configuration may be based on entity type.

E.g. some fields may only be relatevant for member listview, some only to media listview etc.

Or perhaps in Forms or Commerce listview.. or a custom listview in UI Builder or your own implementation in a custom section.