Created attachment 66079 [details] Headers of a tablecontrol could not be moved - screenshots of LO 3.3.4 and LO 3.6.1.1 rc Open a form for editing. Create a tablecontrol-field. You could find this control, when you open "More Controls". You can choose fields, that should be shown in this tablecontrol. When you will change the position of this fields (tableheaders) you have to push the left button of the mouse and move the mouse to the new position. An arrow appears and the field would be moved. This works in LO 3.3.*, LO 3.4.* and LO 3.5.*. When you try the same in LO 3.6.1.1 rc, the symbol for copying the field (tableheaders) appears. But the field isn't copied. There appears only a symbol and you cannot move the field. There is no possibility to move a field from one position to another.
I'm able to reproduce this bug with LO Version 3.6.0.4 (Build ID: 932b512) In my test case, the field is copied after drag and drop.
*** Bug 59254 has been marked as a duplicate of this bug. ***
I set the version to the first LO 3.6 - see comment 1
*** Bug 68539 has been marked as a duplicate of this bug. ***
Have tried to find the first version, where this bug appears. I tested with LO 3.6.0.0 beta1. There it's impossible to move the fields. There are no earlier versions for me available. In https://bugs.freedesktop.org/show_bug.cgi?id=68539 I have also tested with LO 3.5.7.2. In this version the fields could only moved from the right side to the left side. So there is also something buggy inside. I set the version for this bug to 3.6.0.0 beta1
Please attach a document that has the form (not just a word document, an actual document that we can easily test). Marking as NEEDINFO - once you attach please mark as UNCONFIRMED (please don't mark as NEW as it hasn't been independently confirmed)
Created attachment 88288 [details] Open the form for editing - try to move the field "Street" to the left. Why shouldn't I set this Bug to "New"? It is confirmed by many people in LO-forum, also by comment1 in this bug description.
Because it's missing a lot of information that QA would add. Simply saying "I can confirm" isn't enough. Since it's a regression a bibisect will be useful, plus there is no information about operating systems, if it's been tested on 4.1 or newer, etc . . . If you could provide your system info along with the latest version that you've tested on (please don't update the version field, just leave a comment)
Thank you for reporting this issue! I have been able to confirm the issue on: Version 4.1.2.2 & Version 4.2 master from a few days ago Platform: Ubuntu 13.10 x64 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Marking as: New (confirmed) Normal - can prevent high quality work, unless I am missing a workaround for the problem, completely prevents sorting the way you want High - Regression, bumped up from Keywords - regression Whiteboard Status - bibisected + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
Lionel - one for you I suppose ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3dd564c99651edb7fc45bea4afec8e98f7a8aa19 is the first bad commit commit 3dd564c99651edb7fc45bea4afec8e98f7a8aa19 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed May 2 19:14:52 2012 +0200 source-hash-0bbf79005a697c6781047c01f05eb660836a18e1 commit 0bbf79005a697c6781047c01f05eb660836a18e1 Author: Stephan Bergmann <sbergman@redhat.com> AuthorDate: Mon Apr 23 11:47:45 2012 +0200 Commit: Stephan Bergmann <sbergman@redhat.com> CommitDate: Mon Apr 23 11:47:45 2012 +0200 Do not fail for legacy rdb that only contains root key :100644 100644 b453a604fc3c5fb4f63f3aed412de93d20c55f20 30cc0b83db3fdcc1184dc05167bee66d47065710 M ccache.log :100644 100644 5b0c05d5b6e9bda9bd68f447b69ed7bed74e3f33 06d353cf5a0dd1d1225f43c0f21e1401f4316324 M commitmsg :100644 100644 c6128a76d64ef1fe9d7cfd8fbb4cddb737fcf551 e9791ae34f56f896af9eeb3ad1a21850bb54b086 M dev-install.log :100644 100644 c0a3d2e12aaac1a7028a9d2c80d22e60efd1998f 43a4d682bdd87ac9421ebe7a42ce229c9f1acba7 M make.log :040000 040000 39dc0b7004ecedf0b4458a6b1df2c44f75bb8725 ae3ab874138db9d0d407fc0f11d1738a17f398b8 M opt :100644 100644 3098f58f38447b6f729b16c23f3edcc4ae973b8a 27ab6b5b5adb9e65e24651db698082531c3d5593 M patch.log # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # skip: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c git bisect skip 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9 # skip: [1b33e76db9e293bea69b7f814ee90a52a10f7a57] source-hash-cac1f33e839469d884730350e46a21d92fb442f2 git bisect skip 1b33e76db9e293bea69b7f814ee90a52a10f7a57 # bad: [bc003d6498b1bb1188ed2387d87f6723d5a329c7] source-hash-c8218367a0f52206591a5048848fa5292405b6c3 git bisect bad bc003d6498b1bb1188ed2387d87f6723d5a329c7 # good: [644d874f93754099832af82fdd48034d9710692b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4 git bisect good 644d874f93754099832af82fdd48034d9710692b # bad: [5d495e9d278412d3719fe3d18b429d2b34831241] source-hash-4f5c523b97542bdbfe69fb7695bcb9699c66f89f git bisect bad 5d495e9d278412d3719fe3d18b429d2b34831241 # bad: [b3d0d6cf5ddad3c3642ec069bcc2946f7f4b2853] source-hash-f5080ebb7022c9f5d7d7fdca4fe9d19f9bb8cabf git bisect bad b3d0d6cf5ddad3c3642ec069bcc2946f7f4b2853 # good: [897cb6dda02ae841cd1831e132de2aba7821a601] source-hash-212c18430864f110e5a3549c0279b1a2ea4bb6bd git bisect good 897cb6dda02ae841cd1831e132de2aba7821a601 # bad: [5cec9e21c2a7ccf772046a19234d065b40753526] source-hash-33f5acad371bcf838011b3629450e6dcd405a4e9 git bisect bad 5cec9e21c2a7ccf772046a19234d065b40753526 # bad: [3dd564c99651edb7fc45bea4afec8e98f7a8aa19] source-hash-0bbf79005a697c6781047c01f05eb660836a18e1 git bisect bad 3dd564c99651edb7fc45bea4afec8e98f7a8aa19 # good: [dda5f411582f8cab90cb3f9abc456fdadb972afb] source-hash-5553dfe2060cb4a02a827c9774a60e4408d20c33 git bisect good dda5f411582f8cab90cb3f9abc456fdadb972afb # good: [df022a841cf6429cb6e6ccc2036df43aa4f5e9a6] source-hash-61d78aca81f08ac3a0f9eb65799d04d56fbad312 git bisect good df022a841cf6429cb6e6ccc2036df43aa4f5e9a6 # first bad commit: [3dd564c99651edb7fc45bea4afec8e98f7a8aa19] source-hash-0bbf79005a697c6781047c01f05eb660836a18e1
@Robert - wanted to leave a message explaining a bit more why we don't like users marking their own bugs as new. Once a bug is marked as new QA essentially ignores the bug unless we are pinged for a particular reason to look further into it. In this case it was marked as NEW without the proper information - which QA would have requested prior to you marking it as NEW had it been in UNCONFIRMED status. The most pertinent thing missing was the attachment which made my job about 100x faster (even though it was a simple test case, spending QA's time or worse, devs time, coming up with these simple test cases is not ideal as we are often forced to guess and check and hope we are making a test document similar to what the reporter had in mind). For the bare minimum of what we hope for in a bug report: Reporters system specs (OS, and architecture) LibreOffice version If a regression Last known version that it worked (if it's known) and the simplest test case attached to the bug. Having these things makes our job a lot easier, and when we have thousands of bugs to confirm and comment on, the little things help a lot Thanks for the attachment and your patience!
(In reply to comment #11) > @Robert - wanted to leave a message explaining a bit more why we don't like > users marking their own bugs as new. This is a (new) problem for me, when I report bugs. The last bugs I reported switch directly to "New" when I have submitted them. I haven't set my own bugs to "New", when there aren't other people, who could confirm the bugs - but the bugzilla did it (Examples: Bug70674, Bug70827). --------------------------- Operating-System of this bug (or others): What should I write, when I get this message in a Base-forum from Windows-user and I am using Linux? I can't set anything in the platform. The description had also the right information when this bug appears (not the last where it works, see comment5). I know you are doing a good job as QA, but please be more careful when writing something like "if it's been tested on 4.1 or newer" for a bug-report from 2012-08-24. The first I have readed, when I reported bugs: "Write clearly, what you do." - so I added screenshots and text, which should declare. Now I could read: "Add an example database" - for a bug, which only needs an empty table and starting the form-wizard. And then I read, that this bug should get high importance - I don't know why: You could delete fields in the tablecontrol, you could add fields where you want - you only cant move the fields. This is a "cosmetical" Bug, not a functionality of the database broken with this bug. When you set this to "high", much of the other bugs I reported must be "highest".
Thanks for the compliment :) As for priorities, pretty subjective but QA has some general policies that mix severity and priority, we tend to ask people not to change their own priorities as it just irritates developers and makes them distrust the system. Here is the guide that we try to follow at least to some extent: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg So if you report a bug and you think strongly it belongs somewhere in that flowchart, please put that in your comment and we'll take your opinion into consideration :) A lot of the times QA really is "guessing" at how popular a feature is or if there is or is not a workaround is also very important
I confirm it happens on 4.2.6.3.
Adding self to CC if not already on
On pc Debian x86-64 with master sources updated today, just opening the form for editing gave: arn:legacy.osl:8268:1:unotools/source/config/moduleoptions.cxx:585: unknown factory warn:legacy.osl:8268:1:unotools/source/config/moduleoptions.cxx:585: unknown factory warn:legacy.osl:8268:1:svtools/source/brwbox/brwbox2.cxx:1035: BrowseBox::ImplPaintData could not seek back to current row after paint warn:legacy.osl:8268:1:svtools/source/brwbox/brwbox2.cxx:1035: BrowseBox::ImplPaintData could not seek back to current row after paint warn:legacy.osl:8268:1:svtools/source/brwbox/brwbox2.cxx:1035: BrowseBox::ImplPaintData could not seek back to current row after paint warn:legacy.tools:8268:1:sfx2/source/control/bindings.cxx:2182: No cache for OfficeDispatch! warn:legacy.osl:8268:1:svtools/source/brwbox/brwbox2.cxx:1035: BrowseBox::ImplPaintData could not seek back to current row after paint warn:legacy.osl:8268:1:svtools/source/brwbox/brwbox2.cxx:1035: BrowseBox::ImplPaintData could not seek back to current row after paint Then trying to move the field: warn:legacy.osl:8268:5:svx/source/fmcomp/fmgridcl.cxx:265: FmGridHeader::ExecuteDrop: somebody started a nonsense drag operation!!
just some debugging info about the test line which displays "FmGridHeader::ExecuteDrop: somebody started..." sFieldName: Street sCommand: Table sDatasouce: sDatabaseLocation: xConnection.is(): 0 (BTW, I've just noticed a typo for "sDatasource")
Unwinding a bit the lack of datasourcename: OColumnTransferable::extractColumnDescriptor http://opengrok.libreoffice.org/xref/core/svx/source/fmcomp/dbaexchange.cxx#261 285 // build the real descriptor 286 return ODataAccessDescriptor(aDescriptorProps); Then: bool ODADescriptorImpl::buildFrom( const Sequence< PropertyValue >& _rValues ) http://opengrok.libreoffice.org/xref/core/svx/source/form/dataaccessdescriptor.cxx#100 when pValues->Name = "DataSourceName" pValues->Value = <Any: (string) > then: void ODataAccessDescriptor::setDataSource(const OUString& _sDataSourceNameOrLocation) http://opengrok.libreoffice.org/xref/core/svx/source/form/dataaccessdescriptor.cxx#390 "_sDataSourceNameOrLocation" is empty then: 164 void OColumnTransferable::implConstruct( const OUString& _rDatasource 165 ,const OUString& _rConnectionResource 166 ,const sal_Int32 _nCommandType 167 ,const OUString& _rCommand 168 , const OUString& _rFieldName) http://opengrok.libreoffice.org/xref/core/svx/source/fmcomp/dbaexchange.cxx#164 "_rDatasource" is empty then: 86 OColumnTransferable::OColumnTransferable(const Reference< XPropertySet >& _rxForm, 87 const OUString& _rFieldName, const Reference< XPropertySet >& _rxColumn, 88 const Reference< XConnection >& _rxConnection, sal_Int32 _nFormats) 89 :m_nFormatFlags(_nFormats) 90 { must dig on...
86 OColumnTransferable::OColumnTransferable(const Reference< XPropertySet >& _rxForm, 87 const OUString& _rFieldName, const Reference< XPropertySet >& _rxColumn, 88 const Reference< XConnection >& _rxConnection, sal_Int32 _nFormats) 89 :m_nFormatFlags(_nFormats) http://opengrok.libreoffice.org/xref/core/svx/source/fmcomp/dbaexchange.cxx#86 102 _rxForm->getPropertyValue(FM_PROP_DATASOURCE) >>= sDatasource; 103 _rxForm->getPropertyValue(FM_PROP_URL) >>= sURL; gives empty strings. SbaGridControl::DoColumnDrag http://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/browser/sbagrid.cxx#1120 1152 OColumnTransferable* pDataTransfer = new OColumnTransferable(xDataSource, sField, ... So xDataSource doesn't contain all the information. Lionel: any idea if it's the good lead to follow?
This looks relevant: warn:legacy.osl:8027:1:svx/source/form/formcontrolfactory.cxx:207: lcl_getDataSourceIndirectProperties: could not determine the form!
(In reply to Lionel Elie Mamane from comment #20) > This looks relevant: > > warn:legacy.osl:8027:1:svx/source/form/formcontrolfactory.cxx:207: > lcl_getDataSourceIndirectProperties: could not determine the form! How did you retrieve this log? (with master sources? during form edition?) I don't find a way to have it in console.
Created attachment 112455 [details] reproduction example in Writer
(In reply to Julien Nabet from comment #21) > (In reply to Lionel Elie Mamane from comment #20) > > This looks relevant: > > > > warn:legacy.osl:8027:1:svx/source/form/formcontrolfactory.cxx:207: > > lcl_getDataSourceIndirectProperties: could not determine the form! > > How did you retrieve this log? (with master sources? during form edition?) With the attached "reproduction example in Writer". I fixed this warning now (in master), but it does not fix this bug. In Writer, it copies the column. Very imperfectly I must say... no properties are copied except the data source. Which makes me think that we have two separate bugs: 1) The drag'n drop copies instead of moving. 2) In base, nothing happens (the copy fails). And possibly a third one: 3) The copy is partial. Your investigations are interesting for bug "2" in the above list.
(In reply to Lionel Elie Mamane from comment #22) > Created attachment 112455 [details] > reproduction example in Writer With master sources updated today, it's even not possible for me to try a drag n drop since when I select column and try to move it, I've got a symbol indicating it's not possible.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.