|
FOROS PROFESIONALES
WINDEV, WEBDEV y WINDEV Mobile |
| | | | | |
| Iniciado por alwd, 28,ago. 2005 11:01 - 15 respuestas |
| |
| | | |
|
| |
| Publicado el 28,agosto 2005 - 11:01 |
G'day All,
On a current project where I needed detailed control level security, I decided to implement the WD Groupware. On first glance it is not up to the usual Windev standard, the table structure is confusing in names and structure, and the sample code has quite a few serious problems in regard to deleting users and groups and in changing names where the changes are not propagated to all the GPW files resulting in orphan records and lost information.
There is also an issue concerning the Table DoubleClick event, which will activate a button that has been turned off by the groupware. If you have a modify button that is connected to the double click and it is turned off in the groupware for the user, it will still be activated by that user on a table double click.
I would like to know if there are other groupware issues that have been discovered ?
Regards
AL |
| |
| |
| | | |
|
| | |
| |
| Publicado el 28,agosto 2005 - 12:40 |
G'day All,
On a current project where I needed detailed control level security, I decided to implement the WD Groupware. On first glance it is not up to the usual Windev standard, the table structure is confusing in names and structure, and the sample code has quite a few serious problems in regard to deleting users and groups and in changing names where the changes are not propagated to all the GPW files resulting in orphan records and lost information.
Hi Al, in fact the gpw-code IS WinDev standard Look at RAD code .. but in general it's working fine. Of course, one has to polish, debug a lot. Same applies to WDSetup and RAD code. It would be interesting to collect all the fixes, warnings, errors etc in one place, like that which I started with RAD.
There is also an issue concerning the Table DoubleClick event, which will activate a button that has been turned off by the groupware. If you have a modify button that is connected to the double click and it is turned off in the groupware for the user, it will still be activated by that user on a table double click.
I would like to know if there are other groupware issues that have been discovered ?
Regards
AL
In regards to the problem that GPW just turns off single controls like a button control but does not turn off any referencing to that control within other controls. This leads to the paradoxon that f.i. the 'Modify'-button on a Table Window can be disabled by Groupware though will work quite fine when a double-click on the table activates it.
However, I can understand that this one is not too easy for PC Soft to fix. Groupware would have to search the p-code of the compiled application for a reference to any of the disabled controls. Maybe version 25 ...
My suggestion to fix this problem was to add a line in the initialization section of that button (e.g. Modify) on the Table Window which is used on a double-click (I'm using the Modify button on Table windows and the Validate button on Vision windows):
IF MySelf..State = DisplayOnly THEN Table..DoubleClick = ""
True, it's not easy to find the availability of the DoubleClick-property for tables in the Help, because - magically - it's missing from the list of properties for tables (applies to WD8+9, French+English). Which leads to another complaint: In the French Help, properties are sorted by name but not so in the English Help and there is no way to search for a certain word on a given Help-page.
Best regards,
Guenter |
| |
| |
| | | |
|
| | |
| |
| Publicado el 28,agosto 2005 - 13:42 |
G'day Guenter
>It would be interesting to collect all the fixes, warnings, errors etc in one place, like that which I started with RAD.
This is what I have found out to date.
GPWAssociationConfiguration.wdw
Deleting a user using the user delete button
If the first delete in the GPWUserConfiguration file fails it will still try and delete the user in the GPWUserFile. This can leave orphan records in the GPWUserConfiguration file
There is no delete in the GPWConfiguration file. This file contains a record per user and the group_ status of that records is set to false
Modify a user using the button opens the GPWUserForm.
If you change a user login name, the OK button code does not propagate the change into the GPWUserConfiguration file or the GPWConfiguration file. This means more orphan records and the user looses the connection to previously established groups and settings because the displayTable procedure in the calling window sets up a default user when it can't locate a group for the changed user name.
The same thing happens if you open the GPWFormConfiguration window from the modify button in the GPWConfigurationDetails window. Changes to the group are not propagated to the GPWUserConfiguration file or the GPWConfiguration file
The GPWConfigurationDetails window only displays the window file names, which may not be very relevant to the user trying to set access rights. I have always had a table of window names in my projects from my original security coding that I still maintain so I use that to display the correct window title . This method also lets me control which windows are available to the user. An alternative solution might be to use the window description if it can be extracted and added during the build of the "Window" combo box
Regards
Al |
| |
| |
| | | |
|
| | |
| |
| Publicado el 30,agosto 2005 - 01:53 |
G'day Guenter It would be interesting to collect all the fixes, warnings, errors etc in one place, like that which I started with RAD.
This is what I have found out to date. GPWAssociationConfiguration.wdw Deleting a user using the user delete button If the first delete in the GPWUserConfiguration file fails it will still try and delete the user in the GPWUserFile. This can leave orphan records in the GPWUserConfiguration file There is no delete in the GPWConfiguration file. This file contains a record per user and the group_ status of that records is set to false Modify a user using the button opens the GPWUserForm. If you change a user login name, the OK button code does not propagate the change into the GPWUserConfiguration file or the GPWConfiguration file. This means more orphan records and the user looses the connection to previously established groups and settings because the displayTable procedure in the calling window sets up a default user when it can't locate a group for the changed user name. The same thing happens if you open the GPWFormConfiguration window from the modify button in the GPWConfigurationDetails window. Changes to the group are not propagated to the GPWUserConfiguration file or the GPWConfiguration file The GPWConfigurationDetails window only displays the window file names, which may not be very relevant to the user trying to set access rights. I have always had a table of window names in my projects from my original security coding that I still maintain so I use that to display the correct window title . This method also lets me control which windows are available to the user. An alternative solution might be to use the window description if it can be extracted and added during the build of the "Window" combo box Regards Al
Hi Al,
The basic problem with User Groupware is that the structure is very primitive. All files links are linked via text fields which are at the same time used as descriptors (project name, user or group name, etc) in a file. Changing any of these simply breaks the link and means that unless you modify them in the each file manually, you lose the total configuration for that project, user or group.
The incompatibility between the French and English GPW versions mentioned by Guenter is due to the same reason but made worse: not only are the file links text fiels without update but the French and English versions have file and field names in either French or English and the functions expect them to be in the specific language under which the project is currently developped. It is possible to make a French GPW work in a project under WD_US (at least up to v. but only if you have both versions (or international) and use the French DLL. Because the English version substancially lags behind the French this is however not really an acceptable solution either.
Best regards
mat |
| |
| |
| | | |
|
| | |
| |
| Publicado el 30,agosto 2005 - 02:59 |
G'day Mat
I agree entirely with your comments. It concerns me that a company producing database software was unable to construct a proper relational database to implement this functionality and was also unable to code a properly functioning interface.
The whole database is totally insecure. There is no encryption of the data and there is no checksum held to see if changes had been made to the data tables from outside the system. Any table can be seen in plain language and altered with WDMap.
I have patched the holes you mentioned by recoding the delete and modify functions in the windows and will wrap the process inside transactions at some future point to make it a bit more robust.
Despite the flaws the concept works quite well although on a large project it is too complex for clients to operate and we end up sending out pre-prepared groups already setup. The interface to change access to objects is based per window whereas in practice you also want to adjust read/write/view access for a group or a person across the whole project so you need to be able to adjust the state for all Modify buttons etc.
The other point is that if you imagine your data as a spreadsheet then the groupware only functions on the vertical axis to remove columns you still need your own separate mechanisms in place to remove access to individual data on the horizontal axis.
All the GroupWare really needs is for PCSoft to open up the internal groupware commands and we could write our own management process.
Regards
Al |
| |
| |
| | | |
|
| | |
| |
| Publicado el 30,agosto 2005 - 03:22 |
what version of windev are you using?
I ask because I am new to windev and have not used the groupware functions yet and planned to impliment when I moved from 8 to 9.
I am waiting for the shipped version of 9 before migrating. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 30,agosto 2005 - 04:19 |
G'day Mat
I agree entirely with your comments. It concerns me that a company producing database software was unable to construct a proper relational database to implement this functionality and was also unable to code a properly functioning interface.
The whole database is totally insecure. There is no encryption of the data and there is no checksum held to see if changes had been made to the data tables from outside the system. Any table can be seen in plain language and altered with WDMap.
I have patched the holes you mentioned by recoding the delete and modify functions in the windows and will wrap the process inside transactions at some future point to make it a bit more robust.
Despite the flaws the concept works quite well although on a large project it is too complex for clients to operate and we end up sending out pre-prepared groups already setup. The interface to change access to objects is based per window whereas in practice you also want to adjust read/write/view access for a group or a person across the whole project so you need to be able to adjust the state for all Modify buttons etc.
The other point is that if you imagine your data as a spreadsheet then the groupware only functions on the vertical axis to remove columns you still need your own separate mechanisms in place to remove access to individual data on the horizontal axis.
All the GroupWare really needs is for PCSoft to open up the internal groupware commands and we could write our own management process.
Regards
Al
Hi Al,
thanks a lot for your info. Our solution is that we don't use any user specific settings at this time. We set up a parallel user management, allowing other settings like language etc, which is using Groups pre-configured in the groupware. Group names cannot be changed. So, in the end, similar thing as in your case.
I have not had the courage to change groupware windows as I thought they might change in a new version. But I can't see any changes from version 7.0 to 8.0, so maybe I should do the same and amend the code for the modification of user and group names.
One question: our groupware is kept simple by way of groups to avoid conflicts. Do you know how multiple assignments to groups are handled? If two groups result in a different setting for the same object, which takes preference, the more restrictive setting, the more generous setting or coincidence ?
Thanks and regards
mat |
| |
| |
| | | |
|
| | |
| |
| Publicado el 30,agosto 2005 - 04:49 |
G'day Steve
I am using V9. I don't think there have been any changes to the groupware since it was introduced.
Regards
Al |
| |
| |
| | | |
|
| | |
| |
| Publicado el 30,agosto 2005 - 05:06 |
G'day All
When testing projects there is provision to nominate a directory where the test files are located. There is no provision to nominate a directory for the location of test Groupware files, so if they do not exist in the test directory then a set of files is created automatically with a supervisor user. This means that if you want to test a specific set of users and setting you must have thoser groupware files in the test directory.
A directory can be set for groupware in the Workshop menu but this affects the project and is used when compiling so I think it is too dangerous to use for testing purposes, because you may forget to reset it.
Regards
Al |
| |
| |
| | | |
|
| | |
| |
| Publicado el 30,agosto 2005 - 05:46 |
G'day Mat
>Do you know how multiple assignments to groups are handled? If two groups result in a different setting for the same object, which takes preference, the more restrictive setting, the more generous setting or coincidence ?
(Does your derg bite ?)
The user is either a member of a group or not. If the user is a not a member of a group then he is in reality a member of the group "NONE" which is excluded from the group rights setting functions so any settings made are for the individual user. This means that when that user logs on, their user settings take precedence because they have no recognised group.
If a user is a member of a group, then rights are set for that group and the group rights are used when the user logs on.
This means that a user cannot have an indivdual logon and be a member of a recognised group so there is no order of precedence to worry about
Regards
Al |
| |
| |
| | | |
|
| | |
| |
| Publicado el 30,agosto 2005 - 13:13 |
Hi Al,
Regarding file locations, the default is a subdirectory of the data directory. To avoid problems, in my opinion it's best to leave everything at default and then start the groupware in the code rather than automatically. It's actually more simple than it might appear at first. Here's what I use:
// in the Project initialisation
//******************************
// following boolean used for creating an automtic login while developping
vUserGroupware is boolean = OnTestMode() = False
// in a global procedure, called from the project init
//****************************************************
// the path is used in the GPW functions Open and Login. Using fCurrenDir makes
// it independent of where data resides
// "\gpw_"+ProjectInfo corresponds to the default used by Windev
vPath is string=fCurrentDir+"\gpw_"+ProjectInfo
IF vUserGroupware=True THEN
vRes= gpwOpen(vPath,vPath)
IF vRes <>gpwOk THEN RESULT False
oUser:cUserCode = gpwGetUserInfo(gpwInfoLogin)
ELSE
// automatic login for development purposes only
IF oUser:cUserCode ="" THEN
oUser:cUserCode = "MN"
oUser:cUserPW = ""
END
vRes = GPWLogin(oUser:cUserCode,oUser:cUserPW,vPath,vPath)
IF NOT vRes = gpwOk THEN RESULT false
END
Regards
mat |
| |
| |
| | | |
|
| | |
| |
| Publicado el 30,agosto 2005 - 13:26 |
G'day Mat Do you know how multiple assignments to groups are handled? If two groups result in a different setting for the same object, which takes preference, the more restrictive setting, the more generous setting or coincidence ?
(Does your derg bite ?) The user is either a member of a group or not. If the user is a not a member of a group then he is in reality a member of the group "NONE" which is excluded from the group rights setting functions so any settings made are for the individual user. This means that when that user logs on, their user settings take precedence because they have no recognised group. If a user is a member of a group, then rights are set for that group and the group rights are used when the user logs on. This means that a user cannot have an indivdual logon and be a member of a recognised group so there is no order of precedence to worry about Regards Al
Thanks Al. I spent a lot of time on groupware, mostly due to bugs in WD7.5, but I admit not enough on this section. What you are saying is that a user may only be member of one group or none, which I suppose settles the question for Windev. In most other products a user may be a member of several groups, i.e. Windows, which then may lead to the problems mentioned.
Regards
mat |
| |
| |
| | | |
|
| | |
| |
| Publicado el 30,agosto 2005 - 14:58 |
G'day Mat
Luckily we don't need a lot of groups and users and one or our clients has setup a login for each individual user and then has groups with the same user name as the group name. eg User "Construction" is a member of the "Construction" group and this group has its own rights set up. The user then logs in under their own name or as user "Construction". A bit cumbersome but it works ok once it is set up.
Regards
Al |
| |
| |
| | | |
|
| | |
| |
| Publicado el 30,agosto 2005 - 15:01 |
G'day Mat
A very neat solution, thanks very much for posting the code.
Regards
Al |
| |
| |
| | | |
|
| | |
| |
| Publicado el 01,septiembre 2005 - 11:54 |
G'day All
Mat wrote
>We set up a parallel user management, allowing other settings like language etc, which is using Groups pre-configured in the groupware. Group names cannot be changed.
These points are worth emphasising to anyone reading this thread and contemplating using the groupware, even in a minor way.
The data schema is too fragile to play with and the simplest way to preserve it, is to block any changes to group names.
You will need a parallel process to provide other features for the user or groups because it is impossible to alter the groupware structure, as the analysis is locked by PCSoft.
Regards
Al |
| |
| |
| | | |
|
| | |
| |
| Publicado el 27,enero 2015 - 20:07 |
I also have a problem with user groupware. I have assigned rights for a particular report and the user can access the report but on occasion it prevents the user from accessing the report and generates a fatal error and the program must be restarted.
Al a écrit :
G'day All,
On a current project where I needed detailed control level security, I decided to implement the WD Groupware. On first glance it is not up to the usual Windev standard, the table structure is confusing in names and structure, and the sample code has quite a few serious problems in regard to deleting users and groups and in changing names where the changes are not propagated to all the GPW files resulting in orphan records and lost information.
There is also an issue concerning the Table DoubleClick event, which will activate a button that has been turned off by the groupware. If you have a modify button that is connected to the double click and it is turned off in the groupware for the user, it will still be activated by that user on a table double click.
I would like to know if there are other groupware issues that have been discovered ?
Regards
AL |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|