As per current implementation users can purge themselves This can't be undone ....
Is this "a way to disagree" ? On Thu, Apr 26, 2018 at 2:35 PM, Peter Dähn <[email protected]> wrote: > Hi Maxim, > > I will test it during the day.... > > Yes you are right... This need to be done during registration. checkbox > and link to the privacy policy that need to be placed somewhere. > > Agreement for data processing need to be double opt-in. Most likely via > E-Mail. I think an e-mail template that could be changed easily is the most > flexible way. > > And there should a way to disagree further data-processing. "The way to > disagree need to be as easy as the way to agree"... My understanding: that > would be our "soft delete"... If this is used, there should be a way for > the user to reactivate this account. E.g. check registration e-mail and if > it is soft deleted the registration confirm e-mail could have the option to > reactivate the old account or generate a new one > > Back later, when I've tested current build > Greetings Peter > > > > Am 26.04.2018 um 08:09 schrieb Maxim Solodovnik: > > All your comments should be addressed in latest build available > > Could you please re-check? > > This question was not answered ..... > > Additional question: > "Registration-Dialog need to have a button/step to agree the data > processing. And to this belongs a button to disagree." > > I guess user should be able to register only if he/she agree to data > processing > Registration should be impossible if user disagree > So I guess having following controls at registration dialog would be > sufficient: > > 1) "I agree my data will be processed" checkbox > 2) "display agreement" button > > would it be OK? > > On Wed, Apr 25, 2018 at 6:16 PM, Maxim Solodovnik <[email protected]> > wrote: > >> These errors seems to be caused by code changes after testing :( >> I'll double-check it >> >> IP addresses are cleaned up by periodic job. >> Will also add clean by purge >> Thanks for checking! >> >> WBR, Maxim >> (from mobile, sorry for the typos) >> >> On Wed, Apr 25, 2018, 17:33 Peter Dähn <[email protected]> wrote: >> >>> Hi Maxim, >>> >>> first test... >>> >>> purge confirmation dialogue should be different from delete... >>> >>> >>> >>> maybe "Do you really want to purge this item? This can't be undone!" >>> Something like that... >>> >>> After purge I got an 500 internal error page... >>> >>> openmeetings.log: >>> >>> *ERROR 04-25 12:05:13.708 o.a.w.DefaultExceptionMapper:170 >>> [nio-5080-exec-3] - Unexpected error occurred* >>> *java.lang.NullPointerException: zoneId* >>> * at java.util.Objects.requireNonNull(Objects.java:228)* >>> * at java.time.ZoneId.of(ZoneId.java:311)* >>> * at >>> org.apache.openmeetings.util.CalendarHelper.getZoneId(CalendarHelper.java:30)* >>> * at >>> org.apache.openmeetings.util.CalendarHelper.getZoneDateTime(CalendarHelper.java:43)* >>> * at >>> org.apache.openmeetings.util.CalendarHelper.getDate(CalendarHelper.java:47)* >>> * at org.apache.openmeetings.web.co >>> <http://org.apache.openmeetings.web.co>mmon.GeneralUserForm.updateModelObject(GeneralUserForm.java:173)* >>> * at org.apache.openmeetings.web.ad >>> <http://org.apache.openmeetings.web.ad>min.users.UserForm.onModelChanged(UserForm.java:198)* >>> * at org.apache.wicket.Component.mo >>> <http://org.apache.wicket.Component.mo>delChanged(Component.java:2143)* >>> * at org.apache.wicket.Component.se >>> <http://org.apache.wicket.Component.se>tDefaultModelObject(Component.java:3026)* >>> * at >>> org.apache.wicket.IGenericComponent.setModelObject(IGenericComponent.java:81)* >>> * at org.apache.openmeetings.web.ad >>> <http://org.apache.openmeetings.web.ad>min.users.UserForm.updateForm(UserForm.java:266)* >>> * at org.apache.openmeetings.web.ad >>> <http://org.apache.openmeetings.web.ad>min.users.UserForm.purgeUser(UserForm.java:240)* >>> * at org.apache.openmeetings.web.ad >>> <http://org.apache.openmeetings.web.ad>min.users.UserForm.onPurgeSubmit(UserForm.java:214)* >>> * at org.apache.openmeetings.web.ad >>> <http://org.apache.openmeetings.web.ad>min.AdminBaseForm$1.onPurgeSubmit(AdminBaseForm.java:75)* >>> * at org.apache.openmeetings.web.co >>> <http://org.apache.openmeetings.web.co>mmon.FormActionsPanel$3.onSubmit(FormActionsPanel.java:93)* >>> * at org.apache.openmeetings.web.co >>> <http://org.apache.openmeetings.web.co>mmon.ConfirmableAjaxBorder.lambda$new$5f39bb3f$1(ConfirmableAjaxBorder.java:74)* >>> * at org.apache.openmeetings.web.co >>> <http://org.apache.openmeetings.web.co>mmon.ConfirmableAjaxBorder$ConfirmableBorderDialog.onSubmit(ConfirmableAjaxBorder.java:196)* >>> * at >>> com.googlecode.wicket.jquery.ui.widget.dialog.AbstractFormDialog$DialogFormSubmitter.onSubmit(AbstractFormDialog.java:294)* >>> * at >>> org.apache.wicket.markup.html.form.Form.delegateSubmit(Form.java:1268)* >>> * at org.apache.wicket.markup.html.form.Form.process(Form.java:963)* >>> * at >>> org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:787)* >>> * at >>> com.googlecode.wicket.jquery.ui.widget.dialog.AbstractFormDialog.internalOnClick(AbstractFormDialog.java:215)* >>> * at >>> com.googlecode.wicket.jquery.ui.widget.dialog.AbstractDialog$1.onClick(AbstractDialog.java:413)* >>> * at >>> com.googlecode.wicket.jquery.ui.widget.dialog.DialogBehavior.onAjax(DialogBehavior.java:188)* >>> * at com.googlecode.wicket.jquery.core.ajax.JQueryAjaxBehavior.re >>> <http://ore.ajax.JQueryAjaxBehavior.re>spond(JQueryAjaxBehavior.java:173)* >>> * at >>> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:598)* >>> * at >>> org.apache.wicket.core.request.handler.ListenerRequestHandler.internalInvoke(ListenerRequestHandler.java:306)* >>> * at >>> org.apache.wicket.core.request.handler.ListenerRequestHandler.invoke(ListenerRequestHandler.java:280)* >>> * at >>> org.apache.wicket.core.request.handler.ListenerRequestHandler.invokeListener(ListenerRequestHandler.java:222)* >>> * at >>> org.apache.wicket.core.request.handler.ListenerRequestHandler.respond(ListenerRequestHandler.java:208)* >>> * at >>> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:912)* >>> * at >>> org.apache.wicket.request.RequestHandlerExecutor.execute(RequestHandlerExecutor.java:65)* >>> * at >>> org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:283)* >>> * at >>> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:253)* >>> * at >>> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:221)* >>> * at org.apache.wicket.protocol.ws >>> <http://org.apache.wicket.protocol.ws>.AbstractUpgradeFilter.processRequestCycle(AbstractUpgradeFilter.java:70)* >>> * at >>> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:204)* >>> * at >>> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:286)* >>> * at >>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)* >>> * at >>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)* >>> * at >>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)* >>> * at >>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)* >>> * at >>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)* >>> * at >>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)* >>> * at >>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)* >>> * at >>> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:651)* >>> * at >>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)* >>> * at >>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)* >>> * at >>> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:407)* >>> * at >>> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)* >>> * at >>> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:754)* >>> * at org.apache.tomcat.util.net >>> <http://org.apache.tomcat.util.net>.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1376)* >>> * at org.apache.tomcat.util.net >>> <http://org.apache.tomcat.util.net>.SocketProcessorBase.run(SocketProcessorBase.java:49)* >>> * at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)* >>> * at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)* >>> * at >>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)* >>> * at java.lang.Thread.run(Thread.java:745)* >>> >>> this error is also shown after choosing a purged user. Set time_zone >>> manually in db fixed it. >>> time_zone seems to be deleted while purging and then it causes the error. >>> >>> om_user-table will be handled correctly. >>> conference_log preserves the ip-address >>> address-table preserves the address >>> chat-table preserves from_name >>> >>> Did I miss something? >>> >>> >>> Am 25.04.2018 um 09:00 schrieb Peter Dähn: >>> >>> Good morning Maxim, >>> >>> I was alone in the office these days... unfortunatly there were no time >>> left... But I red right in the moment the RUNNING.txt... all a bit >>> different... ;-) >>> >>> I'm going to text it now... give me a bit time... ;-) >>> >>> Am 25.04.2018 um 04:41 schrieb Maxim Solodovnik: >>> >>> Good morning Peter :) >>> >>> were you able to take a look at this issue? >>> >>> On Mon, Apr 23, 2018 at 2:37 PM, Peter Dähn <[email protected]> >>> <[email protected]> wrote: >>> >>> Hi Maxim, >>> >>> I will have a look right now. >>> >>> Greetings Peter >>> >>> >>> Am 21.04.2018 um 18:17 schrieb Maxim Solodovnik: >>> >>> Hello Peter, >>> >>> this is partially implemented >>> Could you please test current implementation using latest nightly build? >>> >>> And maybe you can provide sample "personal data agreement" text? >>> >>> On Wed, Apr 11, 2018 at 6:38 PM, Peter Dähn <[email protected]> >>> <[email protected]> wrote: >>> >>> I try... ;-) >>> >>> >>> Am 11.04.2018 um 13:11 schrieb Maxim Solodovnik: >>> >>> Will write it as a requirement, will see what can be done here >>> Thanks a lot for the quick answers! >>> >>> On Wed, Apr 11, 2018 at 5:34 PM, Peter Dähn <[email protected]> >>> <[email protected]> wrote: >>> >>> ip-address is now a private date... it have to be at least anonymised >>> after 7 (maybe 14 days)... ipv4 addresses delete last 8 recommended 16 >>> bit >>> (192.168.123.0 or 192.168.0.0) and ipv6 preserve first 48 -8 or better >>> 16 >>> Bit (2a00:1234:56:: or 2a00:1234::) Maybe this could be done automated >>> after >>> 7 Days? >>> >>> Greetings Peter >>> >>> Am 11.04.2018 um 09:31 schrieb Maxim Solodovnik: >>> >>> According "Hash algorithm" I planned to use random UUID >>> so All fields will look like this: >>> "Purged_54cd4426-1c0a-4ab8-bb35-eb6d26da99cf" >>> >>> Are you sure IP should be cleaned-up? There will be no chance to >>> "restore" >>> who was this user ..... >>> >>> On Wed, Apr 11, 2018 at 2:18 PM, Peter Dähn <[email protected]> >>> <[email protected]> wrote: >>> >>> Hi Maxim, >>> >>> I think this list is complete and you are right, this is a lot of >>> stuff. >>> >>> The option that you suggest sound much more feasible. From my point of >>> few this should be enough. >>> >>> Hash algorithm need to be state of the art. IP-address in ConferenceLog >>> need to be cleaned. >>> >>> I think this is a good way. >>> >>> Btw... is there is a way/setting to anonymize IP-adresses while >>> logging? >>> Otherwise I need to write a script to do so. Maybe I need to do it >>> anyway to >>> kick out usernames. Logfiles need to be delete after 7 (maybe 14) days >>> or >>> they need to be without any userdata. >>> >>> Greetings Peter >>> >>> >>> Am 11.04.2018 um 06:43 schrieb Maxim Solodovnik: >>> >>> Hello Peter, >>> >>> Here is the high level list of what need to done to "hard delete" user >>> from the system: >>> >>> delete user >>> delete all user contacts (also users, so we might have recursion here) >>> delete user from all groups >>> delete user from room moderators >>> delete all appointments with owner == user >>> delete all calendars with owner == user >>> delete all meeting members in appointments where owner != user >>> delete all Private Messages where user is in to/from fields >>> delete all UserContact + Requests >>> delete all invitation sent by this user >>> delete all private rooms owned by this user >>> delete all user private files/recordings >>> delete all chat messages send/received by this user >>> clean email messages >>> clean all Polls/answers >>> >>> >>> This list scares me a lot :((( >>> >>> So let's discuss the option: "Mark user deleted and clean-up sensitive >>> information" >>> >>> What I would propose: >>> >>> In Admin->User area >>> >>> display all users (deleted should be "read-only" with restore and purge >>> options only) >>> add additional "Purge" button >>> In case Purge will be selected: >>> >>> User will be marked deleted >>> AsteriskSipUser and Address will be replaced with empty objects >>> User fields "age, externaluserid, firstname, lastname, login, >>> pictureuri" >>> will be replaced with "Purged_some_hash" >>> User profile picture will be deleted >>> ChatMessage: fromName will be replaced with "Purged User" >>> MailMessage: should be purged (some search by email will be required) >>> >>> ConferenceLog right now contains userId+UserIp right now, so it is 2 >>> numbers should it be cleaned up? >>> >>> SOAPLogin contains clientURL and doesn't contains userId, so it is >>> impossible to associate SoapLogin object with particular user >>> >>> >>> Would it be enough? >>> >>> >>> On Fri, Apr 6, 2018 at 4:21 PM, Peter Dähn <[email protected]> >>> <[email protected]> wrote: >>> >>> Hi Maxim, >>> >>> hard delete as only option would be the easiest way (for the admin). >>> One >>> doesn't need to remind "hard delete" at a given time... I think it >>> need to >>> be implemented anyway. I thought just the ones that doesn't need to >>> take >>> care about these regulation could keep things as they are now... >>> >>> Greetings Peter >>> >>> >>> Am 06.04.2018 um 10:09 schrieb Maxim Solodovnik: >>> >>> I'm afraid there will be no option to "final delete one record" >>> It will be: perform total clean-up and hard delete all soft deleted >>> records >>> >>> Or better to perform: hard delete as the only option? >>> >>> On Fri, Apr 6, 2018 at 2:44 PM, Peter Dähn <[email protected]> >>> <[email protected]> wrote: >>> >>> Hi Maxim, >>> >>> "soft" and "final delete" should be enough I think... >>> >>> It just need to be "findable" and described for new admins that >>> provide the >>> service in the EU... >>> >>> jira in a second... >>> >>> Greetings Peter >>> >>> >>> Am 05.04.2018 um 17:47 schrieb Maxim Solodovnik: >>> >>> Hello Peter, >>> >>> This sounds like lots of new testing :( >>> Will try to find time and include it in 4.0.3/4.0.4 >>> >>> (have very limited time right now :( ) >>> Will appreciated any help with testing >>> >>> Would it be OK to perform "final delete" in clean-up widget? i.e. >>> delete will be "soft delete", then in if will push "Clean-up" all >>> soft >>> deleted data will be hard deleted ... >>> Or it doesn't worth to have both? only hard delete will be enough? >>> >>> On Thu, Apr 5, 2018 at 5:55 PM, Peter Dähn <[email protected]> >>> <[email protected]> wrote: >>> >>> Hey there, >>> >>> new privacy regulations will take place on the 25th May 2018 in >>> Europe. >>> You >>> could find informations about it by searching for General Data >>> Protection >>> Regulation (EU) 2016/679. >>> >>> To use openmeetings after the 25th of May (in Europe) there need >>> to >>> be a >>> few >>> changes. We use openmeetings integrated. So I will mainly be >>> focused >>> on >>> the >>> room. >>> >>> I have 3 points that are really necessary: >>> >>> 1. User deletion: Datasets of users that will be deleted need to >>> be >>> remove >>> from the database, not just marked as deleted. Probably it is >>> enough >>> to >>> hash >>> those fields. >>> >>> I think critical fields are in table: >>> >>> om_user -> age, externaluserid, firstname, lastname, >>> login, >>> pictureuri (and picture itself) and sip_user_id >>> >>> conferencelog -> email, external_user_id, firstname, >>> lastname, >>> user_id, userip >>> >>> soaplogin -> client_url (contains the ip-address) >>> >>> sipusers (here empty so please check) -> >>> defaultuser, >>> host, >>> ipaddr, name >>> >>> address -> email, fax, phone >>> >>> chat -> from_name >>> >>> e-mail_queue (if not empty) -> recipients, replyto >>> >>> 2. There need to be a place to place a (customized) privacy >>> policy. >>> >>> 3. Registration-Dialog need to have a button/step to agree the >>> data >>> processing. And to this belongs a button to disagree. >>> >>> >>> As far as I can see this need to be done in the first place. I'm >>> sure >>> there >>> are more things to do. Maybe someone can complete it. >>> >>> >>> Greetings Peter >>> >>> >>> >>> >>> -- >>> WBR >>> Maxim aka solomax >>> >>> >>> >>> >>> -- >>> WBR >>> Maxim aka solomax >>> >>> >>> >>> >>> -- >>> WBR >>> Maxim aka solomax >>> >>> >>> >>> >>> >>> >>> > > > -- > WBR > Maxim aka solomax > > -- WBR Maxim aka solomax
