Re: [api-dev] Using XDatabaseDocumentUI.loadComponent with BASIC
Marc Santhoff wrote: Am Donnerstag, den 08.01.2009, 16:18 +0100 schrieb Fernand Vanrie: Frank, Is it also a reasonable RTF to asks that every SubComponent tables, Querys etc been protected by a password or a other protection sheme (from out the API) I think you can achieve user rights discrimination by doing so in the undelying database. It's a standard task for RDBMS. Marc, you are right but when using OO-docs as a frontend-docs then the rights are distributed on base of who has acces to the Frontend-doc . So here the maker of the frondend-doc must decide wath is accesable for the frontend-doc-user . Think at how spreadsheets are secured. Greetz Fernand Drew did and suggested some techniques, search the users and dev lists (at dba). HTH, Marc - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Using XDatabaseDocumentUI.loadComponent with BASIC
Frank Schönheit - Sun Microsystems Germany wrote: Hi Fernand, Is it also a reasonable RTF to asks that every SubComponent tables, Querys etc been protected by a password or a other protection sheme (from out the API) Not exactly sure ... Do you want to specify a password per table/query/form/report? If so, what should be covered by this password? Opening? Editing? using (e.g. using a pwd-protected query in a report)? I *suppose* it's hard to come up with a consistent concept here. (Sure, we could use some established concept like access control lists, but that'd be overkill, for sure). You see, I fail to see the overall picture how such a feature would look like, could you elaborate? Think on how Spreadsheets are protected. DB-doc GUImodifing protection by password DB-doc-SUBcomponent protection on GUI-USE (simpel: a Table, Query, Report, Form can been used or not) Greetz Fernand Ciao Frank - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Using XDatabaseDocumentUI.loadComponent with BASIC
Hi Fernand, You see, I fail to see the overall picture how such a feature would look like, could you elaborate? Think on how Spreadsheets are protected. DB-doc GUImodifing protection by password DB-doc-SUBcomponent protection on GUI-USE (simpel: a Table, Query, Report, Form can been used or not) Hmm, I think this comparison doesn't work here ... When you password-protect a spreadsheet, then the user cannot open it by any means. Not even by writing a macro to load it. When you would password-protect, say, a query, then what would you expect to happen when the user executes a report which uses the query to fetch the data? Should it also request the password? So, what exactly would you say should be protected for a query? Opening it for data entry? That's easy to prevent from the UI, but 3 lines of Basic code could do it, anyway. Preventing the Basic code approach would be more difficult. Even if you do so - 5 lines of Basic code could retrieve the SQL statement which constitutes the query, and the same 3 lines from before can display this statement. Preventing *reading* the SQL statement which constitutes the query would affect *all* places in Base: Every functionality which directly or (especially) indirectly uses the query (not only in Base - think about mail merging) would need to be prepared for access control - quite a *huge* effort. So, the bottom line is: Password protection on a per-object basis either works for the most novice users only, or is extremely expensive to implement. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Using XDatabaseDocumentUI.loadComponent with BASIC
Am Freitag, den 09.01.2009, 09:33 +0100 schrieb Fernand Vanrie: Marc Santhoff wrote: Am Donnerstag, den 08.01.2009, 16:18 +0100 schrieb Fernand Vanrie: Frank, Is it also a reasonable RTF to asks that every SubComponent tables, Querys etc been protected by a password or a other protection sheme (from out the API) I think you can achieve user rights discrimination by doing so in the undelying database. It's a standard task for RDBMS. Marc, you are right but when using OO-docs as a frontend-docs then the rights are distributed on base of who has acces to the Frontend-doc . So here the maker of the frondend-doc must decide wath is accesable for the frontend-doc-user . Think at how spreadsheets are secured. Greetz Fernand I understand your intention, but since it isn't possible to do so it may be sufficient to let the underlying database reject the execution of queries and the change or even retrieval of tables (data). Another approach could be to hide the docs from the gui by removing from the lists shown, but really don't know if that's possible. HTH, Marc - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Using XDatabaseDocumentUI.loadComponent with BASIC
Hallo Frank It gives a better, well-defined state. For instance, when you open a form using the XDatabaseDocumentUI, then it will be tracked by the application main window, and closed automatically when the DB doc is closed. When going via loadComponentFromURL at the forms collection, then this tracking cannot happen. BTW: do you see a way to do the inverse: closing the DB doc when last subcomponent is closed ? Thanks Fernand - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Using XDatabaseDocumentUI.loadComponent with BASIC
Hi Fernand, BTW: do you see a way to do the inverse: closing the DB doc when last subcomponent is closed ? There's no built-in mechanism for doing this (we recently discussed this over there in us...@dba, IIRC). And for doing it via API, a mechanism to be notified of opened/closed sub components is missing :( So: No, I don't think that's possible ATM. Wanna submit an RFE for a notification API? Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Using XDatabaseDocumentUI.loadComponent with BASIC
Frank, Is it also a reasonable RTF to asks that every SubComponent tables, Querys etc been protected by a password or a other protection sheme (from out the API) Greetz Fernand So: No, I don't think that's possible ATM. Wanna submit an RFE for a notification API? Ciao Frank - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Using XDatabaseDocumentUI.loadComponent with BASIC
Am Donnerstag, den 08.01.2009, 16:18 +0100 schrieb Fernand Vanrie: Frank, Is it also a reasonable RTF to asks that every SubComponent tables, Querys etc been protected by a password or a other protection sheme (from out the API) I think you can achieve user rights discrimination by doing so in the undelying database. It's a standard task for RDBMS. Drew did and suggested some techniques, search the users and dev lists (at dba). HTH, Marc - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Using XDatabaseDocumentUI.loadComponent with BASIC
Frank Schönheit - Sun Microsystems Germany wrote: Hi Fernand, Frank S. adviced me to use XDatabaseDocumentUI.loadComponent, instead of loadComponentFromURL with the particular advantage that loadComponentFromURL, does not require the active connection, but calculates it itself. so i tryed this code: oDB = stardesktop.loadComponentFromURL( getDatabaseDocument(DBName).URL, _Blank, 0, array() ) REM getDatabaseDocument are a serie of Functions I picked from Drew Jenssen wait 1000 REM here i have a normal opened DBdocument oForm = oDB.CurrentController.loadComponent(com.sun.star.sdb.application.DatabaseObject.FORM,FormName,FALSE) REM here i run in a Execption telling that No connection to the Database exist XDatabaseDocumentUI also has a method connect :) So your question suggests the connection should be done automatically in the loadComponent implementation ... Hmm. Have to think about this. Please tell me: Gives XDatabaseDocumentUI faster, better, saver connection than the old stuff ?? fernand Ciao Frank - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Using XDatabaseDocumentUI.loadComponent with BASIC
Hi Fernand, Please tell me: Gives XDatabaseDocumentUI faster, better, saver connection than the old stuff ?? It gives a better, well-defined state. For instance, when you open a form using the XDatabaseDocumentUI, then it will be tracked by the application main window, and closed automatically when the DB doc is closed. When going via loadComponentFromURL at the forms collection, then this tracking cannot happen. Also, the loadComponent reuses the connection which the DB doc already established (if so), so you do not need to determine this manually. If no connection was established, yet (XDatabaseDocumentUI.isConnected()), then you need to do so (.connect()) - that might be worth an improvement. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
