Pkp-lib: remote galley and supp files are not displayed on the article page

[bozana]

s also https://forum.pkp.sfu.ca/t/ojs-3-1-wont-show-remote-galleys/34816

[bozana]

@NateWr, should remote galleys and supp files be displayed in the same way as the others (just that they will call another URL)?

[NateWr]

Oooh... that's an oversight! And we have no way to determine if it represents a primary or supplementary galley. I suppose treat it visually as supplementary? Or maybe add an option to remote galleys to select the article component type?

[bozana]

Hmmm... yes, unfortunately... If we would add the component type to the remote galleys, how could we save it -- in the DB table submission_galley_settings?

[ronniebrito]

in our case it is always a final/primary galley, so adding * an option to remote galleys to select the article component type* is a better option...

We need a pragmatic solution, as our site needs to enter production soon. Changing the $galleys populating method seems to be easier than changing database, so could you tell me in what part of OJS code can I change this behaviour?

thank you

[NateWr]

in the DB table submission_galley_settings?

I guess? I'm not that clear on how we determine galley type, but I imagine it will complicate some of the calls we have to the galley DAOs throughout the system, since we can't rely on a File existing to check the component type.

https://github.com/pkp/ojs/blob/master/pages/article/ArticleHandler.inc.php#L106-L126

This might be a good candidate for a function in the GalleyService class for getting galleys, which would encapsulate some of this logic in a reusable way so we can consolidate how we're getting and grouping galleys.

[NateWr]

Oh, and @ronniebrito, the link above shows where the galleys are fetched for the article details view on the frontend.

[bozana]

According to the recent discussion also the remote supp file metadata are wished to be saved in the system... and they are saved as file settings...
Thus I am wondering if it would be possible to actually say that a file is/can be remote...
Hmmmm.... No, I suppose this would pretty much complicate the things...
Also, we cannot display those metadata anywhere because in case of remote supp files or galleys we just redirect to that other URL... Thus I actually do not know why would we save those metadata...
Hmmm.... so maybe just to provide the selection of the component type...
Hmmm.... and a remote publication format would have to have only one component type, while in general it can contain several files of different types...
Phew...

[ronniebrito]

thank you @NateWr ,

in our situation a remote galley (that don`t has a file) is always a primary galley, so just changing code as follow worked fine

foreach ($galleys as $galley) {
                $file = $galley->getFile();
                if (!$file) {               
                                        $primaryGalleys[] = $galley;
                    continue;                   
                }
                if (in_array($file->getGenreId(), $primaryGenreIds)) {
                    $primaryGalleys[] = $galley;
                } elseif (in_array($file->getGenreId(), $supplementaryGenreIds)) {
                    $supplementaryGalleys[] = $galley;
                }
            }

[mfelczak]

Just adding a "me too" to @ronniebrito's remarks, we also have a client who is using remote URLs as primary galleys.

[bozana]

@NateWr, what do you think about remote files? Maybe only for the representation files? At the moment I do not have an overview in my head what would then mean for other functions in the system, but... I will think about it more...

[NateWr]

@bozana Do you mean a new subclass of SubmissionFile?

[bozana]

I mean to have that option/possibility for files -- to store it (remoteURL) for a file and not for a representaiton... I cannot think of consequences fully -- e.g. to have such an entry in the DB table submission_files, where there is actually no real file in the system there, because it is a remote file... Hmmm... But if it is only allowed for representation files we can maybe always check that for them...
It seems that it would be the right way to go, concerning that those metadata (document type and its metadata) are saved on the file level... and that the file is actually somewhere remotely, and not the representation (galley and publication format)... but... it also has to fit into the current data model and functions... Hmmm...
Maybe the tricky part is also to integrate it into file upload...

[NateWr]

I guess I thought it would just be a dummy "file" that we attach to a remote galley, but doesn't exist in the database. Looking over previous comments, though, I see that full metadata is wanted. And I'm not sure whether usage stats are tracked by file or galley. So I guess there's probably a lot of be said for having a file entry in the database. But yeah, it does throw a spanner in the works all over the place. I'd still be tempted to try to handle it at the galley level if possible. But lots of hurdles there.

[NateWr]

I've decided to split the bigger issue of giving remote galleys a file component type and metadata into a different issue: https://github.com/pkp/pkp-lib/issues/3254.

This issue will focus on making sure remote and supplementary files are displayed on the article page for 3.1.1. Remote galleys will be treated as primary galleys.

[NateWr]

PR:
https://github.com/pkp/ojs/pull/1787

@asmecher can you code review? Tests still running.

(And if anyone who's had this issue can test the PR that'd be great!)

[NateWr]

Tests passed.

[asmecher]

Looks good -- thanks, @NateWr. Does this need updating in plugins? (Themes, that is?)

[NateWr]

Oh! Yeah, probably. Did not have my thinking cap on there.

[NateWr]

Done. Closing.