GitLab

* glom/libglom/privs.[h|cc]: get_database_users(): Add documentation
about the case that the result is empty.
* glom/mode_design/users/dialog_users_list.cc: on_button_user_add():
If the users list is empty then warn that something is probably wrong
with the permissions. I would like to warn much earlier if the user is
not a superuser, but I do not know how.
Bug #669178 (alien)

Rename Application to AppWindow and rename the Bakery::App* classes
appropriately too. This is a preparation for using Gtk::Application.

* glom/print_layout/canvas_print_layout.cc: fill_with_data(): Do nothing,
and hint on stdout, if there are no records yet. This avoids several
real warnings later.

* glom/print_layout/canvas_layout_item.[h|cc]: Remove the constructor and
create() that take a LayoutItem, because we should put the CanvasItem in a
canvas (even indirectly) before creating the child item, to avoid this
goocanvas bug: https://bugzilla.gnome.org/show_bug.cgi?id=657592#c16
* glom/mode_design/print_layouts/window_print_layout_edit.[h|cc]:
* glom/print_layout/canvas_print_layout.[h|cc]:
Add and use create_canvas_layout_item_and_add() methods which put the new
canvas item in the canvas before creating its child items based on the
LayoutItem.

This fixes bug #668901 (alien)

* glom/mode_data/box_data.cc: :execute_button_script(): Move the
warning UI into
* glom/utils_ui.[h|cc]: a new script_check_for_pygtk2_with_warning()
method.
* glom/mode_design/fields/dialog_fieldcalculation.cc: on_button_test():
* glom/mode_design/layout/layout_item_dialogs/dialog_buttonscript.cc:
on_button_test_script(): Use the new function here.

* glom/libglom/utils.[h|cc]: Add script_check_for_pygtk().
* Makefile_tests.am:
* tests/test_script_check_for_problems.cc: Add a test for the check
function.
* glom/mode_data/box_data.cc: execute_button_script(): Show a
warning dialog, and do not run the script, if it seems to use pygtk.
This should help with but #669196 (alien) and ##661766 (Andre Klapper) .

* glom/libglom/report_builder.[h|cc]: Return bool
from the private methods and check those results.

* glom/libglom/report_builder.cc: report_build_summary():
Remove any sort clause (ORDER BY) from the FoundSet because that makes
no sense for a single row with summary fields. It looks like recent versions
of PostgreSQL have become more strict about this, producing this error, for
instance:
column invoices.invoice_id must appear in the GROUP BY clause or be used in an aggregate function
* Makefile_tests.am:
* tests/test_selfhosting_new_then_report_summary.cc: Add a test for this.
This fixes bug #669281 (alien)

	* glom/libglom/db_utils.[h|cc]: add_group(): Take a bool superuser
	parameter.
	add_groups_from_document(): Use add_group() instead of executing
	the ADD GROUP query directly, to make sure that we also start
	with some sane table privileges defaults, in case nothing else
	sets the privielges.
	* glom/libglom/document/document.cc: load_after(): Fix a typo
	so that the group privileges are really loaded (and then
	saved again instead of being lost).
	* examples/example_film_manager.glom:
	* examples/example_smallbusiness.glom: Save these with
	useful group privileges, so the groups will be allowed to
	see tables.
	* tests/test_document_load.cc: Test the loading of the group
	privileges.
	Previously the examples were created with groups that could not
	even view the tables, which meant that they could not even
	find out about their existence.
	This deals with the problem found here:
	https://bugzilla.gnome.org/show_bug.cgi?id=669043#c2
	But I would like to show the existence (and structure) of tables
	even if their data cannot be viewed, so there is more work to do.

	* tests/test_selfhosting_new_from_example_operator.cc: Check
	that the group exists before adding a user to it.

	* glom/libglom/db_utils.cc: get_table_names_from_database():
	Slightly improved error checking.
	* glom/libglom/privs.cc: set_table_privileges():
	Warn if a GRANT fails.

* glom/frame_glom.cc: Add a stdout message saying the the
default user has been disabled, because the existing message
about the failure to remove the user looks at first like
a security problem.
I still do not know why removal fails, even though we do
change the ownership of the database.

* glom/base_db.[h|cc]: Move remove_user() and
remove_user_from_group() to
* glom/libglom/db_utils.[h|cc].
* glom/frame_glom.cc:
* glom/mode_design/users/dialog_users_list.cc: Adapted.
* tests/test_selfhosting_new_empty_then_users.cc: Test these
functions.

	* glom/frame_glom.cc: on_menu_developer_developer(): Actually use the
	result of Privs::get_user_is_in_group().
	* tests/test_selfhosting_new_from_example_operator.cc: Test this
	same function here, though this test currently fails anyway.
	Really prevent changing to developer mode for non-developers.
	This fixes bug #669043 (alien)

* glom/libglom/privs.cc: get_table_privileges(): Instead of parsing the
relacl.pg_class field, use the PostgreSQL has_table_privilege()
function, though it needs some strange quoting (see comments).
This code is much simpler now.
* tests/test_selfhosting_new_empty_then_users.cc: Add various other
table, group, and user names, to excercise the code.
This now passes.

* glom/mode_design/users/dialog_new_group.cc:
* glom/mode_design/users/dialog_user.cc: Add includes to fix the build.

* tests/test_selfhosting_new_empty_then_users.cc:
Privs::get_table_privileges() must parse a strange format. This test
shows that it fails if the group name contains spaces.