Bugzilla – Bug 546798
time changes not saved
Last modified: 2009-11-12 22:50:33 UTC
When I change the time & date manually and click on save, the changes are not saved. Although I get a message: "Settings have been written." Maybe the changes are written but the results are not shown in the UI? As this happened on an appliance: how do I provide logs for this event?
Didn't you use appliance Beta1? If yes then it is already fixed in beta2. Logs is available at /srv/www/yast*/logs/
I tried it with Beta 2. At first, the same happened. After trying it twice the whole module crashed :-( Here is the error log: /usr/lib/ruby/gems/1.8/gems/activeresource-2.3.4/lib/active_resource/connection.rb:190:in `handle_response' /usr/lib/ruby/gems/1.8/gems/activeresource-2.3.4/lib/active_resource/connection.rb:173:in `request' /usr/lib/ruby/gems/1.8/gems/activeresource-2.3.4/lib/active_resource/connection.rb:138:in `get' /usr/lib/ruby/gems/1.8/gems/activeresource-2.3.4/lib/active_resource/base.rb:639:in `find_every' /usr/lib/ruby/gems/1.8/gems/activeresource-2.3.4/lib/active_resource/base.rb:582:in `find' /srv/www/yast/lib/yast/service_resource.rb:161:in `permissions' /srv/www/yast/lib/proxy_loader.rb:47:in `load_proxy' /srv/www/yast/vendor/plugins/systemtime/app/controllers/systemtime_controller.rb:56:in `index' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/base.rb:1331:in `send' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/base.rb:1331:in `perform_action_without_filters' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/filters.rb:617:in `call_filters' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/filters.rb:610:in `perform_action_without_benchmark' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue' /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/core_ext/benchmark.rb:17:in `ms' /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime' /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/core_ext/benchmark.rb:17:in `ms' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/rescue.rb:160:in `perform_action_without_flash' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/flash.rb:146:in `perform_action' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/base.rb:532:in `send' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/base.rb:532:in `process_without_filters' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/filters.rb:606:in `process' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/base.rb:391:in `process' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/base.rb:386:in `call' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/routing/route_set.rb:437:in `call' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/dispatcher.rb:87:in `dispatch' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/dispatcher.rb:121:in `_call' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/dispatcher.rb:130:in `build_middleware_stack' /srv/www/yast/lib/yast/rack/static_overlay.rb:47:in `call' /srv/www/yast/lib/yast/rack/static_overlay.rb:47:in `call' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/query_cache.rb:29:in `call' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/connection_adapters/abstract/query_cache.rb:34:in `cache' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/query_cache.rb:9:in `cache' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/query_cache.rb:28:in `call' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/connection_adapters/abstract/connection_pool.rb:361:in `call' /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/head.rb:9:in `call' /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/methodoverride.rb:24:in `call' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/params_parser.rb:15:in `call' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/session/cookie_store.rb:93:in `call' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/failsafe.rb:26:in `call' /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/lock.rb:11:in `call' /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/lock.rb:11:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/lock.rb:11:in `call' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/dispatcher.rb:106:in `call' /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/content_length.rb:13:in `call' /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/handler/fastcgi.rb:56:in `serve' /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/fcgi_handler.rb:103:in `process_request' /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/fcgi_handler.rb:153:in `with_signal_handler' /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/fcgi_handler.rb:101:in `process_request' /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/fcgi_handler.rb:78:in `process_each_request' /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/fcgi_handler.rb:77:in `each' /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/fcgi_handler.rb:77:in `process_each_request' /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/fcgi_handler.rb:76:in `catch' /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/fcgi_handler.rb:76:in `process_each_request' /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/fcgi_handler.rb:51:in `process!' /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/fcgi_handler.rb:23:in `process!' /srv/www/yast/public/dispatch.fcgi:24
Mhm. After deleting cookies and rebooting, the changes were actually saved. The only thing that was resetted was: "Do not change time" This was quite unexpected as the option I chose previously was: "Set manually".
add #2 this log is useless we must fix it, that if exception come from backend to report that exception and not frontend exception which is useless. add #3 It is intended. It should not show your last choice but set how way you want change time.
> It is intended. It should not show your last choice but set how way you > want change time. I think, that this is a quite unexpected behaviour. It also does not mirror the system state correctly. It is also the way I am used to deal with forms on the internet: make a choice and this choice is visualized on screen. What are your experiences with this subject?
It depends if form is for information or for editing. The time form mix both. For information is each other items. I cannot remember how user last time set time. I show new information from target system and user can again set new values. Maybe It should be enought to mention it in flash like time setted manually or via ntp.
Yes, original bug is fixed. But I don't want to close it until Martin agree with time setting behavior.
What do you think about: http://w3.suse.de/~mschmidkunz/webyast_7/time.html This would make it clear, how to set time and the selected could be opened at module start (with timezone being default at first run).
(In reply to comment #9) > What do you think about: > http://w3.suse.de/~mschmidkunz/webyast_7/time.html > > This would make it clear, how to set time and the selected could be opened at > module start (with timezone being default at first run). I see there two problems: 1) As I say you at another bug, timezone and UTC status is not related to setted time, just information about pc location and how to interpret e.g. time from NTP. 2) At this page you cannot see time and date, so you have no idea if you need to fix time or date on target machine What I can improve is to add to flash with success report also note that time is manually set. I take this module as module where admin see current status on target machine and if they need, he can set new state.
Mhm. Sorry, I guess I was confused about the way time is set via the module. What about something like that: Select region [ Europe |v] Select timezone [ Prague |v] Set hardware clock to UTC [ ] (x) Set time manually Date [26.10.2009 |v] Time [16:39 |v] ( ) Set time automatically via NTP What do you think about that? I`ll come up with a mock up tomorrow morning. Cu
I have third option don't change time for case, when user has correct time (UTC time) on target machine, but timezone is bad (e.g. is not in england but in French, which mean that time UTC time set on target machine is good, but local time is bad (need 1 hour change)). But if you think that that case is not valid. I have no problem with removal this case.
assign to martin as he suggest new mock up.
As time & date module layout is also discussed in bnc#554700: let`s move the discussion there. *** This bug has been marked as a duplicate of bug 554700 ***