* Execute Gallery.Create.Post plugin hook during scan
Fix issue where Gallery.Create.Post hook is not executed when a new
gallery is created during scan, when the gallery is created based on the
folder.
* Fix Gallery.Create.Post hook being invoked in transaction
Invoke the Gallery.Create.Post hook during zip scan after the
transaction has been committed. This is necessary to allow the plugin to
access the gallery (using GraphQL API). Otherwise the API obviously uses
a different database transaction which can't find the gallery as it
isn't committed yet.
* Generate screenshot images for markers
In some scenarios it might not be possible to use the preview video or
image of markers, i.e. when only static images are supported like in
Kodi. So generate a static screenshot as well.
* Make generating animated and static image optional for markers
* Use screenshot for markers when preview type is set to static image
Add some form of backwards compatibility in the UI for
`IHierarchicalLabeledIdCriterion`. With this backwards compatibility
it's possible to recall saved filters which use the tags filter.
Otherwise stuff would blow up because the saved filter has a different
structure than what the `IHierarchicalLabeledIdCriterion` expects.
* Add migration to create studio aliases table
* Refactor studioQueryBuilder.Query to use filterBuilder
* Expand GraphQL API with aliases support for studio
* Add aliases support for studios to the UI
* List aliases in details panel
* Allow editing aliases in edit panel
* Add 'aliases' filter when searching
* Find studios by alias in filter / select
* Add auto-tagging based on studio aliases
* Support studio aliases for filename parsing
* Support importing and exporting of studio aliases
* Search for studio alias as well during scraping
* Add migration script for tag relations table
* Expand hierarchical filter features
Expand the features of the hierarchical multi input filter with support
for using a relations table, which only has parent_id and child_id
columns, and support adding an additional intermediate table to join on,
for example for scenes and tags which are linked by the scenes_tags
table as well.
* Add hierarchical filtering for tags
* Add hierarchical tags support to scene markers
Refactor filtering of scene markers to filterBuilder and in the process
add support for hierarchical tags as well.
* List parent and child tags on tag details page
* Support setting parent and child tags
Add support for setting parent and child tags during tag creation and
tag updates.
* Validate no loops are created in tags hierarchy
* Update tag merging to support tag hierarcy
* Add unit tests for tags.EnsureUniqueHierarchy
* Fix applying recursive to with clause
The SQL `RECURSIVE` of a `WITH` clause only needs to be applied once,
imediately after the `WITH`. So this fixes the query building to do just
that, automatically applying the `RECURSIVE` keyword when any added with
clause is added as recursive.
* Rename hierarchical root id column
* Rewrite hierarchical filtering for performance
Completely rewrite the hierarchical filtering to optimize for
performance. Doing the recursive query in combination with a complex
query seems to break SQLite optimizing some things which means that the
recursive part might be 2,5 second slower than adding a static
`VALUES()` list. This is mostly noticable in case of the tag hierarchy
where setting an exclusion with any depth (or depth: all) being applied
has this performance impact of 2,5 second. "Include" also suffered this
issue, but some rewritten query by joining in the *_tags table in one
pass and applying a `WHERE x IS NOT NULL` filter did seem to optimize
that case. But that optimization isn't applied to the `IS NULL` filter
of "exclude". Running a simple query beforehand to get all (recursive)
items and then applying them to the query doesn't have this performance
penalty.
* Remove UI references to child studios and tags
* Add parents to tag export
* Support importing of parent relationship for tags
* Assign stable ids to parent / child badges
* Silence Apollo warning on parents/children fields on tags
Silence warning triggered by Apollo GraphQL by explicitly instructing it
to use the incoming parents/children values. By default it already does
this, but it triggers a warning as it might be unintended that it uses
the incoming values (instead of for example merging both arrays).
Setting merge to false still applies the same behaviour (use only
incoming values) but silences the warning as it's explicitly configured
to work like this.
* Rework detecting unique tag hierarchy
Completely rework the unique tag hierarchy to detect invalid hierarchies
for which a tag is "added in the middle". So when there are tags A <- B
and A <- C, you could previously edit tag B and add tag C as a sub tag
without it being noticed as parent A being applied twice (to tag C).
While afterwards saving tag C would fail as tag A was applied as parent
twice. The updated code correctly detects this scenario as well.
Furthermore the error messaging has been reworked a bit and the message
now mentions both the direct parent / sub tag as well as the tag which
would results in the error. So in aboves example it would now show the
message that tag C can't be applied because tag A already is a parent.
* Update relations on cached tags when needed
Update the relations on cached tags when a tag is created / updated /
deleted so these always reflect the correct state. Otherwise (re)opening
a tag might still show the old relations untill the page is fully
reloaded or the list is navigated. But this obviously is strange when
you for example have tag A, create or update tag B to have a relation to
tag A, and from tags B page click through to tag A and it doesn't show
that it is linked to tag B.
* Unify scraped types
* Make name fields optional
* Unify single scrape queries
* Change UI to use new interfaces
* Add multi scrape interfaces
* Use images instead of image
* Add script offset / delay to Handy support.
Further work on #1376.
Offsets are added to the current video position, so a positive value leads to earlier motion. (The most common setting.)
This is needed because most script times have a consistent delay when compared to the video. (Delay from the API calls to the server should be handled by the server offset calculation.)
* Rename scriptOffset to funscriptOffset
* Correct localisation keys
Co-authored-by: WithoutPants <53250216+WithoutPants@users.noreply.github.com>
* Rebuild image edit using formik
* Prompt on page leave when changes are not saved
* Only enables save when changes are made
* Wrap in <Form onSubmit> (not sure if this does anything)
* Add sorting on image and gallery count to performers
* Make performer table headers translatable
* Add image and gallery count to performers table
* Make sure list table container fits the table
Make the table container minimally as wide as the table. This fixes the
table "overflowing" to the left and right and the left not being
accessible.
* Remove unnecessary truncation in tables
IMO there is no need to truncate the title in the scenes table and the
name in the performers table. This because both tables also contain an
image which means that multiple lines should be possible without really
extending the height of the row. Furthermore both tables contain other
values which might be way longer and also aren't wrapped (like tags and
performers for scenes, and aliases for performers).
* Update unlocalized strings & fix various hard strings
* Fix incorrect placement of ignore_organized in en-US
* Add missing strings
* Fix hard string in PerformerList
* Fix: config race conditions with RWMutex
Added RWMutex to config.Instance which read or write locks
all instances where viper is used.
Refactored checksum manager to only use config and not
viper directly anymore.
All stash viper operations are now "behind" the config.Instance
and thus mutex "protected".
* Rebuild gallery edit using formik
* Prompt on page leave when changes are not saved
* Fixes missing required validation
* Only enables save when changes are made
* Wrap in <Form onSubmit> (not sure if this does anything)
* Fix hierarchical criteria performance issue
Don't apply recursive clause to hierarchical criteria when the depth is
set to 0 (i.e.: no recursion is needed).
This undoes the current performance penalty on for example the studios
page. This as reported in #1519, using a database of 4M images, 30K
scenes and 500 studios. Without this fix loading the studios overview,
with the default of 40 items per page, takes 6 to 7 seconds. With this
fix it only takes 0,07 seconds reverting the performance back to the
pre-hierarchical filtering performance (tested against 508f7b84 which
was the last commit before #1397 was merged).
* Add (not) between modifiers for number criterion
* Extract list filters into dedicated components
Extract the filters from the AddFiltersDialog into custom components.
This allows for further refactorring where components will be bound to
criterions.
* Add placeholders to number and duration criterions
* Add backwards compatibility for saved filters
Co-authored-by: WithoutPants <53250216+WithoutPants@users.noreply.github.com>
