Details
-
Bug
-
Resolution: Inactive
-
Major
-
WCM 4.0.4
-
None
-
Operating System: Windows 2000
Platform: PC
Description
Maybe this scenario will hardly happen, but definitely it is a hole.
While the workflow engine is open, the content to be released is locked and
thus trying to open an authoring page in order to change the content will lead
to a message, saying that the content is locked. This is ok.
BUT if somebody opens an authoring page before the manager opens the workflow
engine, he may apply changes, which will not be seen by the manager and then
the manager could release content, which has not been checked.
TestRail: Results
Attachments
Activity
I did the same as you at your online demo. One browser with "root" login, a
second with "siteadmin". Both go to the Company page (pid 2).
Now siteadmin updates the sub-menu (Management page - pid 9) to "Management 2"
and presses OK. Right after that he opens the "update container"-page once more
and waits...
Meanwhile "root" opens the workflow and sees that "Management" changed
to "Management 2". A lock is shown on the Company page and not on "Management
2" so he would be able to approve "Management 2".
But now "siteadmin" changes the title to "Management 3" and presses OK.
"root" unsuspectingly approves "Management 2", but in reality he
approved "Management 3", which goes live.
Stephane Croisier (Inactive)
added a comment - Tested on the online demo and it works. If for example you open a browser (IE)
with a root login on the home + a second one (Firefox) with the siteadmin login
on the Company page (pid 2) and you update a sub-menu (Management page - pid 9)
then if you go in the workflow with your previous IE browser from the home
page, there is a small yellow lock on the Company page.
There is only one case without lock: when you add (not update) a new container.
The id of the new container in the engine is then still not attributed (="0")
and blocking it will block all the new containers. So there is no check here.
So if there is an update case we missed, could you plz carefully describe which
scenario you tested (if possible on the online demo so we could also redo the
test on our side afterwards). Thnx
Stéphane
Stephane Croisier (Inactive)
added a comment - Tested on the online demo and it works. If for example you open a browser (IE)
with a root login on the home + a second one (Firefox) with the siteadmin login
on the Company page (pid 2) and you update a sub-menu (Management page - pid 9)
then if you go in the workflow with your previous IE browser from the home
page, there is a small yellow lock on the Company page.
There is only one case without lock: when you add (not update) a new container.
The id of the new container in the engine is then still not attributed (="0")
and blocking it will block all the new containers. So there is no check here.
So if there is an update case we missed, could you plz carefully describe which
scenario you tested (if possible on the online demo so we could also redo the
test on our side afterwards). Thnx
Stéphane OK! Try to update the page via a container operation. That's the way I did it.
In a container list I select the Update-Icon of a subpage directly. In this
case the small yellow lock does not appear in the workflow engine.
Benjamin
Stephane Croisier (Inactive)
added a comment - Hello,
Should not be the case. If somebody is editing some content on a sub-page (with
an editing pop-up open), the page will be impossible to validate in the
workflow engine (small yellow lock beside the page in the workflow engine).
Just tested on the online demo (Jahia 4.0.4)and it perfectly works. Please be
sure to test with two different users login (ideally with tho different
browsers to be sure to not reuse the same session).
Stéphane
Stephane Croisier (Inactive)
added a comment - Hello,
Should not be the case. If somebody is editing some content on a sub-page (with
an editing pop-up open), the page will be impossible to validate in the
workflow engine (small yellow lock beside the page in the workflow engine).
Just tested on the online demo (Jahia 4.0.4)and it perfectly works. Please be
sure to test with two different users login (ideally with tho different
browsers to be sure to not reuse the same session).
Stéphane
42 b7010
I have strictly followed Benjamin's scenario, and I have had the same bug.
On screenshot.jpg, we can see that I can validate A page wich title seems to be "Page 2", whereas an other user renamed it "Page 3" with an engine that he had already opened before I opened the workflow popup, and validated this change after I opened the workflow popup.