Groups design

[WithoutPants]

This is intended to serve as design document for the Group concept.

A Group is intended to replace the existing Movie concept. That is, a logical, optionally orderable collection of scenes. The Group concept is intended to be generalised, and open enough to be used for Movies/DVDs, Series, Collections of releases, and Playlists.

This design document will also break down the necessary tasks into manageable units of work.

Current expected tasks are:

• rename Movie to Group in the UI
• adjust necessary backend names (for expediency, its probably best to use the existing movie terms and migrate gradually)
• rename synopsis field to description
• add tags relationship
• add new many-to-many ordered relationship between groups - containing/sub-groups
• improve the UI for manipulating the memberships of objects in groups
• (add ordered relationship to galleries?)
• replace front/back images with generic custom image with label - for example enable poster, background, front_image, back_image or any other label, which can then be used by (any) UI. This concept is intended to be rolled out to other object types.
• (any other necessary general fields?)
• (eventually: custom fields)

Relevant issues: #605, #728, #1352, #1402, #2821, #3201

Design Decisions

Groups are intended to be a generic abstract concept

This means that the meaning and use of the Group concept is left to the user to decide. The design decisions should accommodate the greatest breadth of use cases.

Groups may not contain themselves, but otherwise no restriction on Group membership

A Group may have many containing Groups, and may contain any number of Groups. The only restriction on this relationship is that, like tags, there may not be a cyclic relationship. That is, a group cannot contain itself via direct or indirect relationship.

For example, Group A contains Group B, which contains Group C. Group C cannot contain Group A as this will mean that Group A will contain itself.

The meaning of group membership is left to the user to determine. Example relationships might be:

• "Series" group contains "Movie" groups, each of which contain scenes
• "Playlist" group contains scenes, "Collection" groups contain playlist groups, grouped by theme

Contained Groups relationship will be ordered

This allows specifying an ordered list of movies in a series where the default sorting options are not sufficient.

Contained Groups should be displayed in a dedicated tab/view in the Group detail page

Unlike tags and studios, there could potentially be a large number of sub-Groups for a given group. In the Group detail page, sub-groups should be displayed in their own tab/view and should be able to be filtered like other sub-views. It should also be possible to re-order sub-groups from this view.

[xx790]

Does the work on Group involve better UI for organizing the group content?

I'm already trying to use Movies as containers for any orderable content.
But the user experience managing them feels terribly "backwards" and inconvenient.

Expectation - playlist-like UI where I can drag items to order, with intuitive, quick ways to bulk add items.

Reality - all management happens on individual video page. I have to go through each video page to assign the movie and the position.

[WithoutPants]

Yes, I've added a task to improve the UX for group membership management. You're right in that the current way of doing things is not very user-friendly. I'll spend some time at some point coming up with a UI design. I'd love some suggestions and ideas.

[xx790]

After leaving my comment, I realized bulk addition is possible through Edit dialog for selected scenes. (Couldn't edit the comment because GitHub decided to suspend my account for some reason.)

The issue of editing the order in a Group remains.
I can't see a solution other than some custom UI for orderable lists.
One example that comes to mind - Steam Wishlist:

• ordering only exists on the list page, entry pages have no concern where they appear in the list
  • (in stash, I would rather clean up the Edit tab and keep Group cards, maybe merge into Details tab);
• entry cards in the list have drag handles;
• entry cards also have editable number indication.

Considering all entries in a Group are likely to be closely related and may share naming scheme, it might make sense to provide menu options to order according to title (among other options like dates).
Related issue - numbers in titles are likely to require natural sorting or numbers rather than string sorting.
Word usage - may have to be consistent in distinction between sorting and ordering.

[sleetx]

Yes, I've added a task to improve the UX for group membership management. You're right in that the current way of doing things is not very user-friendly. I'll spend some time at some point coming up with a UI design. I'd love some suggestions and ideas.

I mentioned this in #3469 - My vision is some sort of drag-and-drop heirarchical view like the demo here: https://rhwilr.github.io/vue-nestable/

[echo6ix]

My first post is just seeking some clarity here on the goal of this construct.

From my first quick read, I thought this was akin to the Stash-box Release Group concept. But as I look at the cited relevant issues, I am a little fuzzy on what exactly this will entail.

Is this Group construct going to contain something like both a:

• series release group construct, where "A series is a sequence of separate release groups, releases, recordings, works, artists or events with a common theme. The theme is usually prominent in the branding of the entities in the series and the individual entities will often have been given a number indicating the position in the series."
• release group construct, where "A release group, as the name suggests, is used to group releases into a single logical entity. Every release belongs to one, and only one, release group."

Or is specifically focusing more on the series release group construct?

[WithoutPants]

Conceptually, I think it should be able to accommodate both. The design should be abstract enough that users can determine their own meanings and uses for it. As you mentioned in an earlier revision of your comment, we should consider adding some sort of type field to delineate different group types.

[echo6ix]

Do you have any ideas of a hierarchical structure of how this would work? I think if this can be done first, everything else will flow from that from, from ui to any mandatory fields. I think we should also keep in mind that one of the most request features on stash-box is Release Groups, and perhaps the Stash version should be implemented with stash-box in mind for better eventual synergy/integration.

For example

group
   pool
      type[series; playlist; collection]
      name
      images[]
      tags[]
      content_order[]
   release
      type[movie; scene]
         movie
           movie_type[compilation; etc]
           scene_order[]
      title
      performers[]
      tags[]
      images[poster; cover; front; back; etc]
      production_date
      original_release_date

[echo6ix]

Yes, I edited this section out because I suspected (incorrectly) it might be too presumptuous.

(any other necessary general fields?) [...] (eventually: custom fields)

It's hard to say while being fuzzy on the concept, but for filtering and sorting purposes I assume this would need a descriptive group type kind of field for users to designate the type of specific group they're making. Rather than hardcoding a list of values such as series, playlist, collection, movie, I think it would be a better idea for the values to be blank slate, other than the basic ones I've described, and users could add their own, akin to tags, where their different group types are persistent.

production date. A production date field would be fundamental for non-series release groups. It could just as well be added as a custom field, however it's a special use-case because production field value is the primary calculus for determining performer ages relative to content.

---

I don't think there is much else I can contribute here other than to start the process of clarifying the relationships that exists between release groups specific to the context of adult content, and I'm sure others can do a better job of refining this.

• Scene release group. Used to group scene releases into one logical entity, that all belong to (or strictly derive from) one original scene release, such as redistributions and re-releases. Specific scenes within a movie, such as movie compilations, can often link back to a scene release group.

• Movie release group. Used to group movie releases into one logical entity, that may or may not contain constituents parts (scenes), into one logical entity. Movies can have re-releases and redistributions, and some of their constituent parts (scenes) can be rereleased within other movies, or as standalone scenes.

• Series. Episodic type content, playlists, and custom user collections of movies/scene groups, perhaps even galleries?

---

Looking forward to seeing other people's feedback and ideas here to tie this all together.

[xx790]

I assume this would need a descriptive group type kind of field for users to designate the type of specific group they're making. Rather than hardcoding a list of values such as series, playlist, collection, movie, I think it would be a better idea for the values to be blank slate, other than the basic ones I've described, and users could add their own, akin to tags, where their different group types are persistent.

I would definitely love to be able to set a noun more descriptive of actual content of a group.

Will Groups and Studios get Tags field?
In first approximation, tags can make a substitute of any organization system without adding any new fields.
Then, in my opinion, custom fields could've been designated a tag namespace (or parent tag) to provide more focused tagging experience rather than being a completely new concept with separate management system.

[WithoutPants]

I didn't realise the existing Movie model didn't have Tags, so yes I'll be adding that in.

[sleetx]

I agree with the idea of setting a "group type" field that describes its content more clearly. And then being able to filter on that type of content.

Rather than hardcoding a list of values such as series, playlist, collection, movie, I think it would be a better idea for the values to be blank slate

I disagree. If we can settle on a list of terms, I'd prefer a drop-down field instead of relying on tags. The four terms you mentioned should cover most use cases.

In general I dislike the idea that "you should just use a tag" for everything, and not use fields at all just because of a few edge cases. It's not a good practice, and it leaves things too unstructured for most people to use effectively without the burden of setting up their own tag system.

[WithoutPants]

I think the quoted text was referring to having a free-form text field for the group type field, rather than using a tags field to provide the type (which isn't an approach I'm considering).

If we did go with a free-form text field, then I'd be looking at having the UI component show a dropdown of existing group types, but also allow the user to type their own.

My concern with hard-coding the group type candidate list is that we'll inevitably have requests for new group types to be added based on emerging or niche use cases. To me it only makes sense to hard-code the list if there are specific requirements and behaviours around each type that need to be baked into the core system.

All that said, it's easier to start with a restricted set of values, then open it up later, than to go the other way, so it's definitely not a decision to be taken lightly.

[QxxxGit]

Design looks solid. My only tiny concern is the name Group(s), which may be a little confusing for new user experience. There may be an expectation of Users and User Groups with this name, and initial confusion on how to create playlists, movies, etc. Not sure. Collection(s) is another option, but this may not be necessary. I figured I'd raise it in case.

This may be out of scope but I'd love to see a mechanism akin to .forcegallery to automatically pull in scenes based on certain criteria. For example, if I make a playlist "PMVs" it would be incredibly useful to auto detect new scenes and add them to the playlist. Perhaps the filter tools could be used to achieve this.

[WithoutPants]

There's been a bit of discussion on naming, and if memory serves Group was settled on by the majority. Collection works, but to my mind evokes a larger group of things, and suggests a more specific use case.

As to pulling in scenes automatically, this is something I would expect a plugin would be well suited for.

[nofortran]

This is olddude. My github is nofortran.
The groups concept will be very valuable, but it has to work in tandem with stash-box. Grouping scenes into release groups has more value for stashdb. People may want to keep multiple releases and group them but I suspect its relatively few on the client side. The abstraction will mean that its really just a feature and people will use it creatively.

[sleetx]

I agree, we need full stashbox compatibility before this project can be considered complete. Is there a resource on the stashbox side who can help?

[echo6ix]

Another thought here. Lets assume we have a contiguous file that contains multiple scenes. These are almost exclusively movies but not entirely. IAFD documents the performers (and their limited tags) to each scene in the contiguous "group".

Do we want to implement something like that here? (I would say yes) But how does that fit into this paradigm?

[sleetx]

Regarding the group relationships, I want to ensure there is adequate visibility of parent groups and sub-groups, on the card view AND on the particular group page.

I detailed an issue with Studios in #4811 where the subsidiary studios are not visible on the parent Studio page, despite the card view indicating that it contains subsidiaries.

[WithoutPants]

The group-sub-group relationship is different again from tags/sub-tags and studio/sub-studios. Where there is likely to be a limited number of sub-related objects for tags and studios, we don't have an upper limit on the potential number of sub-groups for a given group, especially for the Collection use-case.

For example, you might have a Collection group consisting of a large number of Movies. Displaying these as a field would not be a good idea.

I think there's a reasonable expectation to page and filter related sub-groups, and as such I think sub-groups should be displayed in a dedicated tab (with count pill). The tab should also provide the functionality to reorder sub-groups. I will add a design decision for this.

[departure18]

I like this idea and as it is i can think of a few ways that this will make Stash better suited to organise my porn collection. But why not widen the group concept, to not just be a container for a collection of videos, why not include images too?

My main motivation for suggesting this is that a good chunk of my collection is scraped OnlyFans / social media posts. If you have an ordered collection of videos & images along with a text field, a date and a time then you have pretty much everything you need to represent a post on OnlyFans or most social media sites.

[WithoutPants]

Images are currently excluded from the design because there is already a logical container for images in the gallery concept, which can also potentially be added to groups. I'm not totally against adding an image relationship, but I am concerned with the conceptual redundancy.

[QxxxGit]

Yeah, in a way, I think Galleries would fit nicely within the Group concept, as a group type. I would imagine, given the expected tasks, galleries would receive a well-needed update with things like improved UI for manipulating items within the group, it would benefit from the generic custom image to select an image rather than necessitate a cover.jpg file, better nested gallery support due to the many-many relationships, and probably other things.

I think with something like the UI improvement for item membership within groups, you would have a consistent UI/UX. Otherwise galleries would be this odd-one-out that conceptually is a grouping anyways.

It's more work but I reckon it would knock out quite a few feature requests to improve galleries due to the general Group functionality.

[WithoutPants]

My intention is to implement the UI work for Groups in a way that makes reusing it for galleries and other types relatively simple. Membership, ordering and custom images are all things that I want to apply to galleries.

[departure18]

An OnlyFans post can contain multiple video and images mixed together. Putting the videos from a post in a group, then adding a gallery containing the images from the same post to that group seems like an inelegant solution.

Looking at the metadata for galleries and movies as they currently are, they don't seem massively different. Title & Name and Details & Synopsis are basically the same. Studio Code, Performers, and Tags will probably be needed to be added to Groups. Aliases and Duration are probably redundant when Movies turn into Groups. Would it not be better, and reduce redundancy to have one container object for all types for media rather than one for images only and one for videos only?

Obviously, i know very little of Stash's internals so i'm almost definitely oversimplifying things. 😄 Though the last two posts give me hope that i'm not totally misguided!

[jhs]

Thank you for this well-considered improvement. Following your"greatest breadth of use cases" suggestion: Will the new Groups provide a way for playlists to have data on start+duration, or Start Marker/Stop Marker, or any such mechanism to play only a part of a scene?

[WithoutPants]

That will be covered separately with #3530 which will allow creating scenes using a subset of a file.

[VonTittyslappen]

I appreciate the changes, but please could an option to be added to allow to rename it from Groups back to Movies?

[echo6ix]

@WithoutPants This is only pertinent to the scenes and movies aspects of Groups. But for reference, MusicBrainz isn't the only platform that has implemented a "Release Group" paradigm. Discogs has a Master Release and Versions paradigm, where Master Release is the primary node, and Versions are all the children. See https://www.discogs.com/master/79018-Duran-Duran-Duran-Duran

Posting this because there might be some concepts or terminology you may find useful. I personally think "Master Release" and "Versions" is a clear and intuitive way to reference original scenes or movies that most people would immediately understand.

[stg-annon]

are we limiting Groups to just Scenes our would we also potentially include other major object types?

Say a user want to group Performers together or Studios? I cant think of a use case for Tags but it that might be something to consider too.

[HereIam80]

I just installed the latest dev release to this how this feature works.

As I said on discord, I was a little bit confused, why the sub groups are missing a filter and sorting options until I found the drag and drop icon to sort the sub groups manually. It is really hard to see if every group has a cover.

While I see the advantages to be able to manually sort items like series in the order you want, I don't know if this is feasible for 100s of movies. Would it be possible to add a sort order "manual" where it would be like it is now but you could also use all the other sorting options if you wanted to?

Also a filter would be useful regardless of how the sorting would be.