Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-25505

UserHash is always generated for anonymous user

    Details

    • Type: Bug Bug
    • Status: Backlog
    • Priority: Blocker Blocker
    • Resolution: Unresolved
    • Affects Version/s: 2014.11, 2015.12.1, 16.02
    • Fix Version/s: None
    • Component/s: None
    • Labels:

      Description

      User hash generation process always returns the anonymous user hash. The problem is due to using /_fos_user_context_hash route for hash generation, which is excluded from siteaccess matching, which ultimately means that user will never be authenticated.

      This can be circumvented by using the original request URI when generating the hash, since FOS HTTP Cache bundle never did use /_fos_user_context_hash route to match the hash generation request, making it again possible to have a siteaccess match.

      EDIT: This also happens on 2014.11, but over there, the above doesn't help because this commit never ended up in 2014.11: https://github.com/ezsystems/ezpublish-kernel/commit/b4b02419847c991d24c5938962d83cda90aaca65 and role ID context hash provider uses the second "inherit" param.

        Issue Links

          Activity

          Edi Modrić created issue -
          Bertrand Dunogier made changes -
          Field Original Value New Value
          Status Open [ 1 ] Confirmed [ 10037 ]
          Hide
          Bertrand Dunogier added a comment -

          Does it also behave this way when a valid user hash is provided ? I can confirm that with the Sf reverse proxy, content was cached even with a session.

          I can indeed confirm this behaviour, but given that the test uses a fake hash...

          Show
          Bertrand Dunogier added a comment - Does it also behave this way when a valid user hash is provided ? I can confirm that with the Sf reverse proxy, content was cached even with a session. I can indeed confirm this behaviour, but given that the test uses a fake hash...
          Hide
          Edi Modrić added a comment -

          As far as I can tell, yes. First, I do a request to /_fos_user_context_hash with a non anonymous session ID to get the valid user hash, and I use the same user hash together with the session ID in the second request and result is the same, no Vary: X-User-Hash.

          Show
          Edi Modrić added a comment - As far as I can tell, yes. First, I do a request to /_fos_user_context_hash with a non anonymous session ID to get the valid user hash, and I use the same user hash together with the session ID in the second request and result is the same, no Vary: X-User-Hash.
          Hide
          Bertrand Dunogier added a comment -

          Thank you for the extra details Edi, it helps. I'll keep updating this issue.

          Show
          Bertrand Dunogier added a comment - Thank you for the extra details Edi, it helps. I'll keep updating this issue.
          Hide
          Edi Modrić added a comment -

          Here is the test with a valid X-User-Hash. First request asks for the hash with a non anonymous session ID, and second request opens the homepage with the received user hash. Notice how Vary: X-User-Hash is still missing.

          eddie@abyss [~/www/netgensite] ( ± master ● ● ) $ curl -v -H "Cookie: eZSESSID=9giikdk4k8rsr8rmt4gp6r39t2" -H "Accept: application/vnd.fos.user-context-hash" http://netgensite.local/_fos_user_context_hash -o /dev/null
            % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                           Dload  Upload   Total   Spent    Left  Speed
            0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 127.0.0.1...
          * Connected to netgensite.local (127.0.0.1) port 80 (#0)
          > GET /_fos_user_context_hash HTTP/1.1
          > Host: netgensite.local
          > User-Agent: curl/7.43.0
          > Cookie: eZSESSID=9giikdk4k8rsr8rmt4gp6r39t2
          > Accept: application/vnd.fos.user-context-hash
          > 
          < HTTP/1.1 200 OK
          < Date: Tue, 01 Mar 2016 09:07:35 GMT
          < Server: Apache/2.4.18 (Ubuntu)
          < X-User-Hash: b1731d46b0e7a375a5b024e950fdb8d49dd25af85a5c7dd5116ad2a18cda82cb
          < Cache-Control: max-age=600, public
          < Vary: Authorization
          < X-Cache-Debug: 1
          < X-Debug-Token: 845dda
          < X-Debug-Token-Link: /_profiler/845dda
          < Content-Length: 0
          < Content-Type: application/vnd.fos.user-context-hash
          < 
            0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
          * Connection #0 to host netgensite.local left intact
          eddie@abyss [~/www/netgensite] ( ± master ● ● ) $ curl -v -H "Cookie: eZSESSID=9giikdk4k8rsr8rmt4gp6r39t2" -H "X-User-Hash: b1731d46b0e7a375a5b024e950fdb8d49dd25af85a5c7dd5116ad2a18cda82cb" http://netgensite.local -o /dev/null 
          * Rebuilt URL to: http://netgensite.local/
            % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                           Dload  Upload   Total   Spent    Left  Speed
            0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 127.0.0.1...
          * Connected to netgensite.local (127.0.0.1) port 80 (#0)
          > GET / HTTP/1.1
          > Host: netgensite.local
          > User-Agent: curl/7.43.0
          > Accept: */*
          > Cookie: eZSESSID=9giikdk4k8rsr8rmt4gp6r39t2
          > X-User-Hash: b1731d46b0e7a375a5b024e950fdb8d49dd25af85a5c7dd5116ad2a18cda82cb
          > 
            0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0< HTTP/1.1 200 OK
          < Date: Tue, 01 Mar 2016 09:08:07 GMT
          < Server: Apache/2.4.18 (Ubuntu)
          < Cache-Control: max-age=0, no-cache, public, s-maxage=300
          < X-Cache-Debug: 1
          < X-Location-Id: 2
          < X-Debug-Token: 1cdf85
          < X-Debug-Token-Link: /_profiler/1cdf85
          < Vary: Accept-Encoding
          < Transfer-Encoding: chunked
          < Content-Type: text/html; charset=UTF-8
          < 
          { [16049 bytes data]
          100 46476    0 46476    0     0  46573      0 --:--:-- --:--:-- --:--:-- 46569
          * Connection #0 to host netgensite.local left intact
          

          Show
          Edi Modrić added a comment - Here is the test with a valid X-User-Hash. First request asks for the hash with a non anonymous session ID, and second request opens the homepage with the received user hash. Notice how Vary: X-User-Hash is still missing. eddie@abyss [~/www/netgensite] ( ± master ● ● ) $ curl -v -H "Cookie: eZSESSID=9giikdk4k8rsr8rmt4gp6r39t2" -H "Accept: application/vnd.fos.user-context-hash" http://netgensite.local/_fos_user_context_hash -o /dev/null % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 127.0.0.1... * Connected to netgensite.local (127.0.0.1) port 80 (#0) > GET /_fos_user_context_hash HTTP/1.1 > Host: netgensite.local > User-Agent: curl/7.43.0 > Cookie: eZSESSID=9giikdk4k8rsr8rmt4gp6r39t2 > Accept: application/vnd.fos.user-context-hash > < HTTP/1.1 200 OK < Date: Tue, 01 Mar 2016 09:07:35 GMT < Server: Apache/2.4.18 (Ubuntu) < X-User-Hash: b1731d46b0e7a375a5b024e950fdb8d49dd25af85a5c7dd5116ad2a18cda82cb < Cache-Control: max-age=600, public < Vary: Authorization < X-Cache-Debug: 1 < X-Debug-Token: 845dda < X-Debug-Token-Link: /_profiler/845dda < Content-Length: 0 < Content-Type: application/vnd.fos.user-context-hash < 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 * Connection #0 to host netgensite.local left intact eddie@abyss [~/www/netgensite] ( ± master ● ● ) $ curl -v -H "Cookie: eZSESSID=9giikdk4k8rsr8rmt4gp6r39t2" -H "X-User-Hash: b1731d46b0e7a375a5b024e950fdb8d49dd25af85a5c7dd5116ad2a18cda82cb" http://netgensite.local -o /dev/null * Rebuilt URL to: http://netgensite.local/ % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 127.0.0.1... * Connected to netgensite.local (127.0.0.1) port 80 (#0) > GET / HTTP/1.1 > Host: netgensite.local > User-Agent: curl/7.43.0 > Accept: */* > Cookie: eZSESSID=9giikdk4k8rsr8rmt4gp6r39t2 > X-User-Hash: b1731d46b0e7a375a5b024e950fdb8d49dd25af85a5c7dd5116ad2a18cda82cb > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0< HTTP/1.1 200 OK < Date: Tue, 01 Mar 2016 09:08:07 GMT < Server: Apache/2.4.18 (Ubuntu) < Cache-Control: max-age=0, no-cache, public, s-maxage=300 < X-Cache-Debug: 1 < X-Location-Id: 2 < X-Debug-Token: 1cdf85 < X-Debug-Token-Link: /_profiler/1cdf85 < Vary: Accept-Encoding < Transfer-Encoding: chunked < Content-Type: text/html; charset=UTF-8 < { [16049 bytes data] 100 46476 0 46476 0 0 46573 0 --:--:-- --:--:-- --:--:-- 46569 * Connection #0 to host netgensite.local left intact
          Hide
          Bertrand Dunogier added a comment -

          I can confirm that the behaviour is wrong.

          It is a session issue somehow it seems.

          When creating the hash through /_fos_user_context_hash, done there, the current role is anonymous (e.g. not logged in), and we get the anonymous hash. That's the one we send with further requests.

          But when verifying the hash, as added in 1.3.7, at this place, the role id is the right one.

          In the Response listener, since the hash that got generated based on session data differs from the one passed in the request, cache is disabled.

          Show
          Bertrand Dunogier added a comment - I can confirm that the behaviour is wrong. It is a session issue somehow it seems. When creating the hash through /_fos_user_context_hash , done there , the current role is anonymous (e.g. not logged in), and we get the anonymous hash. That's the one we send with further requests. But when verifying the hash, as added in 1.3.7, at this place , the role id is the right one. In the Response listener, since the hash that got generated based on session data differs from the one passed in the request, cache is disabled.
          Hide
          Bertrand Dunogier added a comment -

          Until we know better, I'll block 1.3.7.

          Show
          Bertrand Dunogier added a comment - Until we know better, I'll block 1.3.7.
          Hide
          Edi Modrić added a comment -

          We also need to make sure that hardcoded anonymous user hash from VCL file also keeps on working.

          It's probably wise to block everything >= 1.3.7, since future versions will probably behave the same.

          Show
          Edi Modrić added a comment - We also need to make sure that hardcoded anonymous user hash from VCL file also keeps on working. It's probably wise to block everything >= 1.3.7, since future versions will probably behave the same.
          Hide
          Edi Modrić added a comment -

          I had a similar issue in TagsBundle where repository user was still anonymous in router I implemented, when it should not have been.

          I was not able to figure out why, so I just implemented sudo i tag repository

          https://github.com/netgen/TagsBundle/commit/945c31f87da59d468584ead3255469f46be8239d

          Show
          Edi Modrić added a comment - I had a similar issue in TagsBundle where repository user was still anonymous in router I implemented, when it should not have been. I was not able to figure out why, so I just implemented sudo i tag repository https://github.com/netgen/TagsBundle/commit/945c31f87da59d468584ead3255469f46be8239d
          Hide
          Bertrand Dunogier added a comment - - edited

          This problem comes from https://jira.ez.no/browse/EZP-23580.

          The issue was that sub-requests to /_fos_user_context_hash would match the default siteaccess if using URI part matching. Since no URI part would match, the default siteaccess would be stored in the request, and the master request would not be matched again, leading to unexpected behaviour.

          The fix was to exclude the /_fos_user_context_hash route from siteaccess matching, making it the only route for which there is no siteaccess.

          The SecurityListener won't login the user since there is no siteaccess.

          This confirms that the user-hash is always the anonymous one. It would need to be tested on other versions, as it sounds possible that stable versions are also affected.

          Show
          Bertrand Dunogier added a comment - - edited This problem comes from https://jira.ez.no/browse/EZP-23580 . The issue was that sub-requests to /_fos_user_context_hash would match the default siteaccess if using URI part matching. Since no URI part would match, the default siteaccess would be stored in the request, and the master request would not be matched again, leading to unexpected behaviour. The fix was to exclude the /_fos_user_context_hash route from siteaccess matching , making it the only route for which there is no siteaccess. The SecurityListener won't login the user since there is no siteaccess. This confirms that the user-hash is always the anonymous one. It would need to be tested on other versions, as it sounds possible that stable versions are also affected.
          Bertrand Dunogier made changes -
          Link This issue relates to EZP-23580 [ EZP-23580 ]
          Hide
          Bertrand Dunogier added a comment -

          Note: this also means that marking http-cache-bundle 1.3.7 as conflicting won't fix anything.

          Show
          Bertrand Dunogier added a comment - Note: this also means that marking http-cache-bundle 1.3.7 as conflicting won't fix anything.
          Bertrand Dunogier made changes -
          Labels cache http
          Bertrand Dunogier made changes -
          Affects Version/s 2016.02 [ 14501 ]
          Bertrand Dunogier made changes -
          Summary No Vary: X-User-Hash with FOS HTTP Cache bundle 1.3.7 UserHash is always generated for anonymous user
          André Rømcke made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16255 ]
          André Rømcke made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16257 ]
          Edi Modrić made changes -
          Description After upgrading FOS HTTP Cache bundle from version 1.3.6 to 1.3.7, Vary header is missing "X-User-Hash" value when request contains the X-User-Hash header.

          Curl call that verifies the problem:

          With FOS HTTP Cache Bundle 1.3.6 (notice the presence of "X-User-Hash" in Vary header):

          {code}
          eddie@abyss [~/www/netgensite] ( ± master ● ● ) $ curl -v -H 'X-User-Hash: 123' http://netgensite.local -o /dev/null
          * Rebuilt URL to: http://netgensite.local/
            % Total % Received % Xferd Average Speed Time Time Time Current
                                           Dload Upload Total Spent Left Speed
            0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 127.0.0.1...
          * Connected to netgensite.local (127.0.0.1) port 80 (#0)
          > GET / HTTP/1.1
          > Host: netgensite.local
          > User-Agent: curl/7.43.0
          > Accept: */*
          > X-User-Hash: 123
          >
          < HTTP/1.1 200 OK
          < Date: Fri, 26 Feb 2016 13:09:24 GMT
          < Server: Apache/2.4.18 (Ubuntu)
          < Cache-Control: public, s-maxage=300
          < X-Cache-Debug: 1
          < Vary: X-User-Hash,Accept-Encoding
          < X-Location-Id: 2
          < X-Debug-Token: e0ece9
          < X-Debug-Token-Link: /_profiler/e0ece9
          < Transfer-Encoding: chunked
          < Content-Type: text/html; charset=UTF-8
          <
          { [16058 bytes data]
          100 48793 0 48793 0 0 61178 0 --:--:-- --:--:-- --:--:-- 61144
          * Connection #0 to host netgensite.local left intact
          {code}

          With FOS HTTP Cache Bundle 1.3.7 (notice the absence of "X-User-Hash" in Vary header):

          {code}
          eddie@abyss [~/www/netgensite] ( ± master ● ● ) $ curl -v -H 'X-User-Hash: 123' http://netgensite.local -o /dev/null
          * Rebuilt URL to: http://netgensite.local/
            % Total % Received % Xferd Average Speed Time Time Time Current
                                           Dload Upload Total Spent Left Speed
            0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 127.0.0.1...
          * Connected to netgensite.local (127.0.0.1) port 80 (#0)
          > GET / HTTP/1.1
          > Host: netgensite.local
          > User-Agent: curl/7.43.0
          > Accept: */*
          > X-User-Hash: 123
          >
            0 0 0 0 0 0 0 0 --:--:-- 0:00:04 --:--:-- 0< HTTP/1.1 200 OK
          < Date: Fri, 26 Feb 2016 13:11:14 GMT
          < Server: Apache/2.4.18 (Ubuntu)
          < Cache-Control: max-age=1, no-cache, public, s-maxage=300
          < X-Cache-Debug: 1
          < X-Location-Id: 2
          < X-Debug-Token: 6951ee
          < X-Debug-Token-Link: /_profiler/6951ee
          < Vary: Accept-Encoding
          < Transfer-Encoding: chunked
          < Content-Type: text/html; charset=UTF-8
          <
          { [16049 bytes data]
          100 48793 0 48793 0 0 10669 0 --:--:-- 0:00:04 --:--:-- 14487
          * Connection #0 to host netgensite.local left intact
          {code}
          User hash generation process always returns the anonymous user hash. The problem is due to using /_fos_user_context_hash route for hash generation, which is excluded from siteaccess matching, which ultimately means that user will never be authenticated.

          This can be circumvented by using the original request URI when generating the hash, since FOS HTTP Cache bundle never did use /_fos_user_context_hash route to match the hash generation request, making it again possible to have a siteaccess match.
          Bertrand Dunogier made changes -
          Link This issue relates to EZP-25533 [ EZP-25533 ]
          Edi Modrić made changes -
          Affects Version/s 2014.11 [ 13681 ]
          Edi Modrić made changes -
          Description User hash generation process always returns the anonymous user hash. The problem is due to using /_fos_user_context_hash route for hash generation, which is excluded from siteaccess matching, which ultimately means that user will never be authenticated.

          This can be circumvented by using the original request URI when generating the hash, since FOS HTTP Cache bundle never did use /_fos_user_context_hash route to match the hash generation request, making it again possible to have a siteaccess match.
          User hash generation process always returns the anonymous user hash. The problem is due to using /_fos_user_context_hash route for hash generation, which is excluded from siteaccess matching, which ultimately means that user will never be authenticated.

          This can be circumvented by using the original request URI when generating the hash, since FOS HTTP Cache bundle never did use /_fos_user_context_hash route to match the hash generation request, making it again possible to have a siteaccess match.

          EDIT: This also happens on 2014.11, but over there, the above doesn't help for some reason.
          Edi Modrić made changes -
          Description User hash generation process always returns the anonymous user hash. The problem is due to using /_fos_user_context_hash route for hash generation, which is excluded from siteaccess matching, which ultimately means that user will never be authenticated.

          This can be circumvented by using the original request URI when generating the hash, since FOS HTTP Cache bundle never did use /_fos_user_context_hash route to match the hash generation request, making it again possible to have a siteaccess match.

          EDIT: This also happens on 2014.11, but over there, the above doesn't help for some reason.
          User hash generation process always returns the anonymous user hash. The problem is due to using /_fos_user_context_hash route for hash generation, which is excluded from siteaccess matching, which ultimately means that user will never be authenticated.

          This can be circumvented by using the original request URI when generating the hash, since FOS HTTP Cache bundle never did use /_fos_user_context_hash route to match the hash generation request, making it again possible to have a siteaccess match.

          EDIT: This also happens on 2014.11, but over there, the above doesn't help because this commit never ended up in 2014.11: https://github.com/ezsystems/ezpublish-kernel/commit/b4b02419847c991d24c5938962d83cda90aaca65 and role ID context hash provider uses the second "inherit" param.
          Bertrand Dunogier made changes -
          Status Confirmed [ 10037 ] Backlog [ 10000 ]
          Bertrand Dunogier made changes -
          Status Backlog [ 10000 ] Development [ 3 ]
          Assignee Bertrand Dunogier [ bertrand.dunogier@ez.no ]
          Bertrand Dunogier made changes -
          Status Development [ 3 ] Development Review [ 10006 ]
          Bertrand Dunogier made changes -
          Status Development Review [ 10006 ] InputQ [ 10001 ]
          Assignee Bertrand Dunogier [ bertrand.dunogier@ez.no ]
          Show
          Bertrand Dunogier added a comment - PR https://github.com/ezsystems/ezpublish-kernel/pull/1602
          Bertrand Dunogier made changes -
          Remote Link This issue links to "PR ezsystems/ezpublish-kernel#1602 (Web Link)" [ 16265 ]
          Bertrand Dunogier made changes -
          Status InputQ [ 10001 ] Development [ 3 ]
          Assignee Bertrand Dunogier [ bertrand.dunogier@ez.no ]
          Bertrand Dunogier made changes -
          Status Development [ 3 ] Development Review [ 10006 ]
          Hide
          Bertrand Dunogier added a comment - - edited

          Might be a false positive, waiting for confirmation on the PR.

          Varnish is configured (3, 4), when requesting the user hash, to copy the Request URI to a x-fos-original-url. This header is then read by the OriginalRequestListener, and used to create the _ez_original_request.

          This does not prevent us from documenting that N repositories require N domains: the user hash request will be cached for the first value of the x-fos-original-header, and won't vary on it.

          Show
          Bertrand Dunogier added a comment - - edited Might be a false positive, waiting for confirmation on the PR. Varnish is configured (3, 4), when requesting the user hash, to copy the Request URI to a x-fos-original-url . This header is then read by the OriginalRequestListener, and used to create the _ez_original_request . This does not prevent us from documenting that N repositories require N domains: the user hash request will be cached for the first value of the x-fos-original-header , and won't vary on it.
          Bertrand Dunogier made changes -
          Status Development Review [ 10006 ] Backlog [ 10000 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16412 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16412 ] This issue links to "Page (eZ Documentation)" [ 16412 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16412 ] This issue links to "Page (eZ Documentation)" [ 16412 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Sarah Haïm-Lubczanski (Inactive) made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Sarah Haïm-Lubczanski (Inactive) made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16412 ] This issue links to "Page (eZ Documentation)" [ 16412 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16412 ] This issue links to "Page (eZ Documentation)" [ 16412 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16412 ] This issue links to "Page (eZ Documentation)" [ 16412 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Alex Schuster made changes -
          Workflow EZ* Development Workflow [ 97885 ] EZEE Development Workflow [ 108082 ]
          Bertrand Dunogier made changes -
          Assignee Bertrand Dunogier [ bertrand.dunogier@ez.no ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Confirmed Confirmed
          3d 1h 26m 1 Bertrand Dunogier 29/Feb/16 4:40 PM
          Confirmed Confirmed Backlog Backlog
          3d 5h 44m 1 Bertrand Dunogier 03/Mar/16 10:25 PM
          Backlog Backlog Development Development
          2s 1 Bertrand Dunogier 03/Mar/16 10:25 PM
          Development Review Development Review InputQ InputQ
          8s 1 Bertrand Dunogier 03/Mar/16 10:25 PM
          InputQ InputQ Development Development
          20s 1 Bertrand Dunogier 03/Mar/16 10:25 PM
          Development Development Development Review Development Review
          8s 2 Bertrand Dunogier 03/Mar/16 10:25 PM
          Development Review Development Review Backlog Backlog
          18h 26m 1 Bertrand Dunogier 04/Mar/16 4:51 PM

            People

            • Assignee:
              Unassigned
              Reporter:
              Edi Modrić
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated: