Description: When I hide a table with the menu Tools > Table Filter then any query based on this table can always access it. But with Form it shows an error message when 'Content type' is a Table based on the hidden one. It is good thing to let Form to access an hidden table like in query. (When doing tests please save, close then re-open the .odb file) Steps to Reproduce: 1.Hide the table with menu Tools > Table Filter 2.Save the file, close, then reopen it 2.Open the form 3.An error message box is displayed Actual Results: Error message box Expected Results: No error Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 7.0.6.2 Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: fr-FR (en_US); UI: en-US Calc: threaded
Created attachment 175794 [details] Table missing error message
Created attachment 175795 [details] Open the different forms. Form connected to table with "Analyze SQL - Yes" don't find the table. Have tested it with different forms. Only the form, which is linked to a table and is set to "Analyze SQL → 'Yes'" shows an error. All other forms will show the content. But: All other forms will only show the content. The content is write protected. I would prefer to show a warning "content is write protected, because table is hidden" or something else. And then: Open the form in write protected mode. My system: OpenSUSE 15.2 64bit rpm Linux. Tested with different versions of LO, fails in LO 7.2.2.2, also in LO 6.4.7.2. Could be a bug introduced by OOo.
For my usage the write protection is not good idea. The goal is not to prevent table modification because this can be done on the server. The fact to hide a table is just for good looking and good design for the user working space on the screen, then display only essential tables. It help user to not have to navigate through too many table structure. Thanks for all.
(In reply to intmail01 from comment #3) > For my usage the write protection is not good idea. The goal is not to > prevent table modification because this can be done on the server. You are right. Hiding tables in Base is only for good looking - couldn't be protected. But for this moment all queries will show a hidden table also write protected. So this bug is: Show also the table write protected in a form. An enhancement would be: Don't set a table write protected, if it is only set unvisible in Base.
It all comes down to what people expect when they mark the table as excluded from display in the list of tables. On the one hand, it could be argued marking a table as filtered, which is something usually an admin would do, should work to completely make that table unaccessible to any user within the Base UI space. On the other hand, it could also be argued that the Base UI should be capable of managing the user determined rights to see and/or interact with any table that the DBA has authorised. Clearly, the current filter mechanism doesn't do either of these completely.
Adding Julien and Lionel for their input, if they wish to comment.
Created attachment 175822 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I had the error message. I noticed this log on console: warn:connectivity.parse:11353:11353:connectivity/source/parse/sqliterator.cxx:2024: Adding error com.sun.star.sdbc.SQLException message: The database does contain neither a table nor a query named "starter". /home/julien/lo/libreoffice/connectivity/source/parse/sqliterator.cxx:2017 SQLState: HY000 ErrorCode: 1000 So I retrieved a bt from this part.
I got the same log with Form_Source_Table so not relevant.
The difference is in this part: 2319 switch (m_nCommandType) 2320 { 2321 case CommandType::TABLE: 2322 { 2323 impl_resetTables_nothrow(); 2324 if ( bDoEscapeProcessing ) 2325 { 2326 Reference< XNameAccess > xTables( impl_getTables_throw() ); 2327 if ( xTables->hasByName(m_aCommand) ) 2328 { 2329 } 2330 else 2331 { 2332 OUString sMessage( DBA_RES( RID_STR_TABLE_DOES_NOT_EXIST ) ); 2333 throwGenericSQLException(sMessage.replaceAll( "$table$", m_aCommand ),*this); 2334 } 2335 } 2336 else 2337 { 2338 sCommand = "SELECT * FROM "; 2339 OUString sCatalog, sSchema, sTable; 2340 ::dbtools::qualifiedNameComponents( m_xActiveConnection->getMetaData(), m_aCommand, sCatalog, sSchema, sTable, ::dbtools::EComposeRule::InDataManipulation ); 2341 sCommand += ::dbtools::composeTableNameForSelect( m_xActiveConnection, sCatalog, sSchema, sTable ); 2342 } 2343 } With SQL Analyze at no, LO goes into "else" from line 2336 with SQL Analyze at yes, LO goes into "if" from line 2324 and since "starter" isn't found, it throws at line 2333 (see https://opengrok.libreoffice.org/xref/core/dbaccess/source/core/api/RowSet.cxx?r=c7f8a54e#2324)
Now about the functional, I don't know at all what should be expected or not.
(In reply to Julien Nabet from comment #9) > 2327 if ( xTables->hasByName(m_aCommand) ) Seems the table isn't only hidden. It has been pushed somewhere else and doesn't exist for the code "hasByName" When I have a look with xray: The tables should be read from oDatabaseDocument.Datasource.Tables.ElementNames or oDatabaseDocument.Datasource.Tables.hasByName Seems it is looking also at DatasSource.TableFilter, which will show the names of the tables, which aren't hidden.
Dear intmail01, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Buggy behavior still exists in LO 7.6.2.1 on OpenSUSE 15.4 64bit rpm Linux. 1. If a table is hidden by Tools → Tablefilter a form couldn't connect directly to the table. But a query could connect and a form connecting to a query or SQL-code could connect also. This different behavior is a bug. 2. What do we expect? I expect: Hiding a table should be only hide the table and nothing else. It shouldn't write protect the table, it shouldn't report this table doesn't exist. With this expected behavior there are 2 bugs: 1. Every contact to the table should give the same behavior. 2. Hidden tables are only hidden and no other "feature" (like "not exists" or "write protected") has to be added.
(In reply to Robert Großkopf from comment #13) > Buggy behavior still exists in LO 7.6.2.1 on OpenSUSE 15.4 64bit rpm Linux. > > 1. If a table is hidden by Tools → Tablefilter a form couldn't connect > directly to the table. But a query could connect and a form connecting to a > query or SQL-code could connect also. This different behavior is a bug. > > 2. What do we expect? I expect: Hiding a table should be only hide the table > and nothing else. It shouldn't write protect the table, it shouldn't report > this table doesn't exist. > @Robert : I would agree with you. The current approach is inconsistent. Hiding a table, or rather filtering a table from the list visible to the user shouldn't prevent a form configured to analyse SQL relating to that table if we accept that a query to that table will still function, and a form, based on that query, is still functional.