Details

    • Epic Name:
      SiteAccess & UI improvments

      Description

      SiteAccess is partly taken into account in UI, however not in:

      • preview url
      • rest url
      • .. and besides UI won't work inside siteaccess when matching is on url, it always need to be on root of domain name

      This causes problems, especially for beginners setting up the software and not following every step correctly, or for people that want to setup different SA setups. So we need to make a decion how this should work, and find a way to take it into account, by passing the right url to preview, and by sending siteaccess by X-SiteAccess via CAPI to REST API as it does not support prefix on URL and so on.

      This Epic needs Spec, cause if we want to have a drop down to select site (access) in the future, this would imply overall UI (login, admin, ..) is loaded in the context of the repository, and not SA, while content and page sections for instance should take it into account. Also need to have multi site setups in mind here in regards to permissions.

        Issue Links

          Issues in Epic

            Activity

            Hide
            André Rømcke added a comment - - edited

            PM: Flagged this issue as customer issues are coming in for both Platform and Studio these days so we need to make a decision on how UI and siteacceesses are supposed to work together soon.

            recent related issues:

            • EZP-25638 & EZP-25672 : Content Type screen takes siteaccess language into account in wrong way
            • EZP-25668 : Admin UI default create content as eng-GB even though the siteaccess only is configured for nor-NO
            • And then a whole bunch of Studio issues, however there it is a bit more clear as you are clearly within a siteaccess (insite/page) context

            Proposal: If we can verify that Repository (REST and underlying API) don't take siteaccess settings into account* (besides database, aka repository), then the following would right now make the most sense and might be the way forward:

            • Platform UI is by default repository centric and ignores siteaccess settings by default
              • For this to work there needs to be a way to choose interface language, this can be a cookie remembered drop-down on login screen which list all languages in repository by their human readable name, or we would need to force user to pick it after login and tie it to account (which we don't know before login suceeds).
            • Certain parts of the application will take SiteAccess into account via some form of selector, currently preview and Studio page mode
              • Both will need a reliable way to load a sitaccess on current domain (aka /preview/<SA>), to avoid that users needs to login again for the preview if it for instance need to take host or port number into account.

            This implies that on multi repo setups, that some host matching is done to pick any siteacesss within the right repository that is intended to be edited on the current install, so correct url for ui will always be /ez, and correct url for REST api is always /api/ on same domain.

            * afaik it is only taken into account in UrlAliasService as it uses siteaccess languages as prioritized languages, so afaik we are mostly good, but Bertrand Dunogier would need to confirm regarding REST API.

            IMPORTANT: This means we clearly don't go the same way as in legacy, rather opposite, however this fits the most with many of the choices we have already made over the last years of UI and API development, and also with how MultiSite UI is currently planned.

            /cc ping Roland Benedetti [~david.liedle@ez.no]

            Show
            André Rømcke added a comment - - edited PM: Flagged this issue as customer issues are coming in for both Platform and Studio these days so we need to make a decision on how UI and siteacceesses are supposed to work together soon. recent related issues: EZP-25638 & EZP-25672 : Content Type screen takes siteaccess language into account in wrong way EZP-25668 : Admin UI default create content as eng-GB even though the siteaccess only is configured for nor-NO And then a whole bunch of Studio issues, however there it is a bit more clear as you are clearly within a siteaccess (insite/page) context Proposal: If we can verify that Repository (REST and underlying API) don't take siteaccess settings into account* (besides database, aka repository) , then the following would right now make the most sense and might be the way forward: Platform UI is by default repository centric and ignores siteaccess settings by default For this to work there needs to be a way to choose interface language, this can be a cookie remembered drop-down on login screen which list all languages in repository by their human readable name, or we would need to force user to pick it after login and tie it to account (which we don't know before login suceeds) . Certain parts of the application will take SiteAccess into account via some form of selector, currently preview and Studio page mode Both will need a reliable way to load a sitaccess on current domain (aka /preview/<SA> ) , to avoid that users needs to login again for the preview if it for instance need to take host or port number into account. This implies that on multi repo setups, that some host matching is done to pick any siteacesss within the right repository that is intended to be edited on the current install, so correct url for ui will always be /ez , and correct url for REST api is always /api/ on same domain. * afaik it is only taken into account in UrlAliasService as it uses siteaccess languages as prioritized languages, so afaik we are mostly good, but Bertrand Dunogier would need to confirm regarding REST API. IMPORTANT : This means we clearly don't go the same way as in legacy, rather opposite, however this fits the most with many of the choices we have already made over the last years of UI and API development, and also with how MultiSite UI is currently planned. /cc ping Roland Benedetti [~david.liedle@ez.no]
            Hide
            David Christian Liedle (Inactive) added a comment -

            Roland Benedetti and I discussed this, and agree with staying repository centric. I'll let him add any detailed feedback.

            Show
            David Christian Liedle (Inactive) added a comment - Roland Benedetti and I discussed this, and agree with staying repository centric. I'll let him add any detailed feedback.
            Hide
            Roland Benedetti added a comment -

            From a conceptual point of view, I think your proposal André is absolutely how I understand our new application logic. So it's indeed a +1 for me.
            PlatformUI is not anymore an "eZ Platform" site, it's not a site, it's not developed with templates, it's fundamentally different and the content repository concept need to be channel agnostic. So yes, it's clearly different from the previous eZ Publish concept, but that's no news.

            This said, if from an implementation perspective, you would need or benefit to rely on some sort of specific "system site accesses" for Platform UI ('ez"), and some specific SA for the API access ("api"), I'd be totally fine (as long as they are not exposed in Studio UI or in the Preview). This is implementation discussion and I leave it to you.

            Show
            Roland Benedetti added a comment - From a conceptual point of view, I think your proposal André is absolutely how I understand our new application logic. So it's indeed a +1 for me. PlatformUI is not anymore an "eZ Platform" site, it's not a site, it's not developed with templates, it's fundamentally different and the content repository concept need to be channel agnostic. So yes, it's clearly different from the previous eZ Publish concept, but that's no news. This said, if from an implementation perspective, you would need or benefit to rely on some sort of specific "system site accesses" for Platform UI ('ez"), and some specific SA for the API access ("api"), I'd be totally fine (as long as they are not exposed in Studio UI or in the Preview). This is implementation discussion and I leave it to you.
            Hide
            Douglas Hammond added a comment -

            Not supporting siteaccess limits use cases such as multi-site/single-repository and multi-site/multi-repository setups as legacy supports, specifically when it is not the same user administrating all sites. Also limits the migration path for such sites.

            How would one handle different content_root's in admin UI if siteaccess is not supported? I know this is a legacy admin feature, but it is hard not to compare the two, and as content_root' is supported, it seemed that would be the direction.

            As you can define what repository each site access is to use, it makes sense that the admin for that siteaccess would be handled in the same manner.

            In a repository centric admin UI there becomes a disconnect from what legacy admin provided and what admin UI would provide. Is the intent to have admin UI for just administrators of repositories and not other types of users such as editors? Users specific to a siteaccess would loose a tremendous amount of functionality legacy supported such as customized admin based on siteaccess. Going forward developers will have to create new admins instead of being able to leverage admin UI as they once could in legacy.

            If the intention of admin UI stays strictly repository centric and we forgo siteaccess support in admin UI, how would one select what repository to use if multiple are setup? I believe there was talk about having the ability to select a repository in UI admin. This still has it's own complications such as permissions and who can see and switch among the available repositories.

            Show
            Douglas Hammond added a comment - Not supporting siteaccess limits use cases such as multi-site/single-repository and multi-site/multi-repository setups as legacy supports, specifically when it is not the same user administrating all sites. Also limits the migration path for such sites. How would one handle different content_root's in admin UI if siteaccess is not supported? I know this is a legacy admin feature, but it is hard not to compare the two, and as content_root' is supported, it seemed that would be the direction. As you can define what repository each site access is to use, it makes sense that the admin for that siteaccess would be handled in the same manner. In a repository centric admin UI there becomes a disconnect from what legacy admin provided and what admin UI would provide. Is the intent to have admin UI for just administrators of repositories and not other types of users such as editors? Users specific to a siteaccess would loose a tremendous amount of functionality legacy supported such as customized admin based on siteaccess. Going forward developers will have to create new admins instead of being able to leverage admin UI as they once could in legacy. If the intention of admin UI stays strictly repository centric and we forgo siteaccess support in admin UI, how would one select what repository to use if multiple are setup? I believe there was talk about having the ability to select a repository in UI admin. This still has it's own complications such as permissions and who can see and switch among the available repositories.
            Hide
            André Rømcke added a comment - - edited

            Douglas:

            • Part of the equation here is that we might move in the direction of exposing some of [Multi]Site administration to UI, which implies moving some of it's logic to repository, including content root settings. If backend UI remains limited by site scope that would not be applicable in the same way.
            • Another part is that we'll need to re think backend login permissions, it could have limitation for which sites you see
            • Regarding repository it is then still separated, so you will still be able to customize UI per repository, or maybe even per site group, we need to identify this better once concept of Site is conceived.

            Either way we have some wireframing to do here, to be able to have something concrete to discuss around this.

            Show
            André Rømcke added a comment - - edited Douglas: Part of the equation here is that we might move in the direction of exposing some of [Multi] Site administration to UI, which implies moving some of it's logic to repository, including content root settings. If backend UI remains limited by site scope that would not be applicable in the same way. Another part is that we'll need to re think backend login permissions, it could have limitation for which sites you see Regarding repository it is then still separated, so you will still be able to customize UI per repository, or maybe even per site group, we need to identify this better once concept of Site is conceived. Either way we have some wireframing to do here, to be able to have something concrete to discuss around this.
            Hide
            Gaetano Giunta added a comment - - edited

            I'd say that before wireframing there should be clear usecases identified

            such as:
            a. having different goups of editors being able to edit (and view) only sub-sites within a single repo (quite common)
            b. having different goups of editors seeing the admin in different languages (probably easy even if we separate the admin ui from siteaccesses)
            c. having different goups of editors seeing vastly different admins (as stated by Andre above)
            => hard to spec here, but this in the past was done via a siteaccess. I'll try to elaborate:

            • normal admin is kept as 'failsafe admin'
            • editorial admin adds new buttons everywhere (and corresponding controllers), renames many existing buttons, removes other

            It is of course possible to introduce a new concept to allow this 'many different admin ui', but I wonder if it would not just be better suited to be tied to siteaccesses in the end

            Show
            Gaetano Giunta added a comment - - edited I'd say that before wireframing there should be clear usecases identified such as: a. having different goups of editors being able to edit (and view) only sub-sites within a single repo (quite common) b. having different goups of editors seeing the admin in different languages (probably easy even if we separate the admin ui from siteaccesses) c. having different goups of editors seeing vastly different admins (as stated by Andre above) => hard to spec here, but this in the past was done via a siteaccess. I'll try to elaborate: normal admin is kept as 'failsafe admin' editorial admin adds new buttons everywhere (and corresponding controllers), renames many existing buttons, removes other It is of course possible to introduce a new concept to allow this 'many different admin ui', but I wonder if it would not just be better suited to be tied to siteaccesses in the end
            Hide
            Roland Benedetti added a comment -

            Interesting discussion, and thanks for your point Douglas Hammond.
            To clarify my answer:

            • I am supporting the idea that André brought: PlatformUI is repository centric and not working like a siteaccess.
            • But I also think it definitely need to be aware of the SA (which was for me in the "Certain parts of the application will take SiteAccess into ..." part)

            It is very clear that the use case "multisite, single repo" is not something we want to compromise. This needs to be possible, and done well. Sorry if I didn't bring that in my comment. That Platform UI is repository centric is one thing, but we need to keep a way to link the repository to the delivery layer: site accesses or APIs. We'll definitely have to explore this more I have the impression.

            Show
            Roland Benedetti added a comment - Interesting discussion, and thanks for your point Douglas Hammond . To clarify my answer: I am supporting the idea that André brought: PlatformUI is repository centric and not working like a siteaccess. But I also think it definitely need to be aware of the SA (which was for me in the "Certain parts of the application will take SiteAccess into ..." part) It is very clear that the use case "multisite, single repo" is not something we want to compromise. This needs to be possible, and done well. Sorry if I didn't bring that in my comment. That Platform UI is repository centric is one thing, but we need to keep a way to link the repository to the delivery layer: site accesses or APIs. We'll definitely have to explore this more I have the impression.
            Hide
            Douglas Hammond added a comment - - edited

            @Roland.Benedetti I went back and re-read the description and comments and I do see a few points I missed that you pointed out thank you.

            Show
            Douglas Hammond added a comment - - edited @Roland.Benedetti I went back and re-read the description and comments and I do see a few points I missed that you pointed out thank you.

              People

              • Assignee:
                Unassigned
                Reporter:
                André Rømcke
              • Votes:
                1 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated: