Issue 110184 - Documentbound macros not executed when file is loaded vial API
Summary: Documentbound macros not executed when file is loaded vial API
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOO320m12
Hardware: All Windows XP
: P2 Trivial (vote)
Target Milestone: OOo 3.3
Assignee: joerg.skottke
QA Contact: issues@framework
URL:
Keywords:
Depends on:
Blocks: 111112
  Show dependency tree
 
Reported: 2010-03-17 11:09 UTC by joerg.skottke
Modified: 2017-05-20 10:22 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description joerg.skottke 2010-03-17 11:09:20 UTC 
Testcase f_security_macrosecurity.bas

While loading test files with document bound macros the macros are not executed
if the security level is low or medium. This is (until now ;-)) not reproducible
manually.
Comment 1 Stephan Bergmann 2010-03-17 11:38:51 UTC 
.
Comment 2 carsten.driesner 2010-03-17 11:53:04 UTC 
cd->mav: Do you have an idea why this can happen?
Comment 3 mikhail.voytenko 2010-03-17 12:09:51 UTC 
mav->jsk: Does the test implementation use the correct value for
"MacroExecutionMode" parameter in MediaDescriptor? If the parameter is not set,
no macro execution is the default behavior for API calls.
Comment 4 carsten.driesner 2010-06-01 10:04:29 UTC 
cd->mav: Please take over.

cd->jsk: Could you please answer the question from Mikhail?
Comment 5 mikhail.voytenko 2010-06-01 10:38:25 UTC 
Taking over.
Comment 6 joerg.skottke 2010-06-01 16:06:13 UTC 
I used an API call to set the macro security level prior to running the test,
However, i suggest that i take a look at a recent build to confirm the problem.
I guess it would be helpful if we had a reproducible scenario.
Comment 7 mikhail.voytenko 2010-07-05 13:58:28 UTC 
Changing the target to OOo3.4. Please declare it as a schowstopper if you
believe that it should be fixed for OOo3.3.
Comment 8 mikhail.voytenko 2010-07-27 13:45:10 UTC 
As jsk has reported the problem looks to affect OOO330_m1 as well.
Comment 9 joerg.skottke 2010-07-27 13:47:56 UTC 
Retarget to 3.3, raising priority to 2.
Scenario for reproduction is available
Comment 10 mikhail.voytenko 2010-08-03 10:51:31 UTC 
mav->jsk: The problem seems to be triggered by calling convertToURL() twice in
the scenario.
The original problem lies in convertToURL() call that is used in automation
tests. If the call gets an URL instead of system path it produces an invalid URL
by introducing additional slashes ( "file://///..." ). Sending to you as discussed.
Comment 11 joerg.skottke 2010-08-04 08:49:36 UTC 
The autotest should be modified not to do the conversion at the start of the
test but to leave this to the file-handling functions (hFileOpen).
Comment 12 joerg.skottke 2010-08-10 10:38:56 UTC 
Started
Comment 13 joerg.skottke 2010-08-13 08:11:44 UTC 
Fixed
Comment 14 joerg.skottke 2010-08-13 08:47:51 UTC 
Verified