[Bug 673] New: attachments in iCalendar 2.0 events/todos not supported
by bugzilla＠meego.com
http://bugzilla.meego.com/show_bug.cgi?id=673
Summary: attachments in iCalendar 2.0 events/todos not
supported
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: Netbook
OS/Version: IA
Status: NEW
Severity: enhancement
Priority: Medium
Component: SyncML
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: jingke.zhang(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-syncml-bugs(a)meego.bugs
Estimated Hours: 0.0
This issue is from BMO#2427 (http://bugzilla.moblin.org/show_bug.cgi?id=2427)
Description From pohly 2009-05-14 12:11:33 PST (-) [reply]
Copied from
https://sourceforge.net/tracker/?func=detail&aid=2158008&group_id=146288&...
http://www.scheduleworld.com/jforum/posts/list/2070.page
iCalendar 2.0 can store attachments, but Evolution and therefore
SyncEvolution currently don't do that properly. In outgoing items only a
local file name is included. Need to patch this for sending and extract
file when importing?!
To implement this in 0.9, we need to:
* extend the field list
* extend the mimeprofile
* change EvolutionCalendarSource so that strips incoming file,
saves them locally, reinserts them when sending back
I have no clue how this is done in Evolution. Need to investigate and then do
the same. Might have to check with our colleagues in London on how libjana does
it (if it supports attachements at all).
------- Comment #1 From Zhiqiang 2009-06-15 02:43:46 PST (-) [reply] -------
reassign this bug to Yongsheng
------- Comment #2 From yongsheng zhu 2009-06-21 20:18:40 PST (-) [reply]
-------
(In reply to comment #0)
> To implement this in 0.9, we need to:
> * extend the field list
> * extend the mimeprofile
My understanding of these 2 items is that we should add/modify configuration
items in the configuration file(syncevolution.xml) for synthesis. I don't know
whether there is any doc/url link to describe how to configure sythesis.
------- Comment #3 From pohly 2009-06-22 02:43:27 PST (-) [reply] -------
(In reply to comment #2)
> (In reply to comment #0)
> > To implement this in 0.9, we need to:
> > * extend the field list
> > * extend the mimeprofile
> My understanding of these 2 items is that we should add/modify configuration
> items in the configuration file(syncevolution.xml) for synthesis.
Correct.
> I don't know
> whether there is any doc/url link to describe how to configure sythesis.
Here's an introduction for the Synthesis data handling and XML config ("Data
Modeling and Handling"):
http://moblin.org/documentation/syncevolution/pim-data-synchronization-wh...
The detailed documentation about the configuration is mentioned there:
XML Configuration Reference for Synthesis SyncML Server&Client Products
http://www.synthesis.ch/indefero/index.php/p/libsynthesis/source/tree/mas...
------- Comment #4 From yongsheng zhu 2009-06-30 01:28:41 PST (-) [reply]
-------
change target milestone to future for it is urgent to add this feature
------- Comment #5 From yongsheng zhu 2009-06-30 01:53:11 PST (-) [reply]
-------
correction for last comment:
delay target milestone to 'future' for it is not time to fix this issue.
--
Configure bugmail: http://bugzilla.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
12 years, 5 months
[Bug 672] New: "client-test -h" configure funambol_[12] by default
by bugzilla＠meego.com
http://bugzilla.meego.com/show_bug.cgi?id=672
Summary: "client-test -h" configure funambol_[12] by default
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: Netbook
OS/Version: IA
Status: NEW
Severity: enhancement
Priority: Low
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: jingke.zhang(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
This issue is from BMO#2402 (http://bugzilla.moblin.org/show_bug.cgi?id=2402)
Description From shuangeeer 2009-05-14 05:59:20 PST (-) [reply]
Run "client-test -h" via command line will create configuration for funambol_1
and funambol_2 be default. User may just want to check the help info but not
really run it.
Steps:
==================
1. check no configuration named funambol_[12] in ~/.config/syncevolution/
2. run "client-test -h" in terminal
3. check directories named funambol_[12] are created in
~/.config/syncevolution/
------- Comment #1 From pohly 2009-06-09 05:36:30 PST (-) [reply] -------
(In reply to comment #0)
> Run "client-test -h" via command line will create configuration for funambol_1
> and funambol_2 be default. User may just want to check the help info but not
> really run it.
Agreed. Currently the configs are created whenever client-test is run, simply
because there is no explicit command line option which could trigger that.
The underlying reason for this deficiency is that main() in client-test is just
the test runner. It has no means of communicating command line options to
individual tests and the code which creates the configs because that is not
part of the CPPUnit concepts.
I don't have a good idea how to improve that, though.
--
Configure bugmail: http://bugzilla.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
12 years, 5 months
[Bug 671] New: service setting changes should be tested with server right away
by bugzilla＠meego.com
http://bugzilla.meego.com/show_bug.cgi?id=671
Summary: service setting changes should be tested with server
right away
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: Netbook
OS/Version: IA
Status: NEW
Severity: enhancement
Priority: Low
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: jingke.zhang(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
This issue is from BMO#2143 (http://bugzilla.moblin.org/show_bug.cgi?id=2143)
Description From jku 2009-05-11 03:45:55 PST (-) [reply]
Whenever settings are changed, we should do a test with the server to see that
the changes are valid.
Setting as enhancement, no idea how much work this is.
------- Comment #1 From pohly 2009-05-11 04:15:11 PST (-) [reply] -------
That's a good point.
We would have to be careful not to disrupt client and server state while
checking because that would be unexpected by users. This rules out starting a
sync session with the real client config.
But we could contact the server with a dummy client ID and check at least some
aspects this way:
* local data sources (is there really a memo database?!)
* credentials
* URIs
I'll take this, with low priority...
--
Configure bugmail: http://bugzilla.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
12 years, 5 months
[Bug 668] New: Synthesis error codes and explanation
by bugzilla＠meego.com
http://bugzilla.meego.com/show_bug.cgi?id=668
Summary: Synthesis error codes and explanation
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: Netbook
OS/Version: IA
Status: NEW
Severity: enhancement
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: jingke.zhang(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
This issue is from BMO#2069 (http://bugzilla.moblin.org/show_bug.cgi?id=2069)
Description From pohly 2009-05-08 04:43:03 PST (-) [reply]
It would be nice if we had good explanations for the status codes generated
during a sync, both for individual sync sources and the overall sync result.
Right now the SyncEvolution command line simply prints the status code as part
of the sync reports.
Let's gather status codes which occurred in reality in this issue together with
an explanation of the different failures, perhaps we can come up with some
helpful texts for users.
------- Comment #1 From jku 2009-05-23 05:47:29 PST (-) [reply] -------
A specific group which I haven't worked on yet is SyncML return codes. It seems
these are codes 10000-20000 (subtract 10000 to get the SyncML error).
I just saw a 10412 (for all sources, next sync worked fine).
Log says:
RECEIVED STATUS 200 for for command 'Replace' (outgoing MsgID=5, CmdID=5)
- SourceRef (localID) = 'pas-id-4A0D398300000044'
Found matching command 'Replace' for Status
chunked object received status 200 instead of 213 --> aborting session
[2009-05-23 13:09:42.291] 'SessionAbort' - Aborting Session, Status=412,
Spec says 412 is:
"Incomplete command. The requested command failed on the
recipient because it was incomplete or incorrectly formed. The
recipient SHOULD specify the portion of the command that was
incomplete or incorrect in the Item element type in the Status."
------- Comment #2 From pohly 2009-06-09 07:39:07 PST (-) [reply] -------
Error code 20043 = LOCERR_TRANSPFAIL is returned if the server sends back a
non-SyncML reply (bug #3041).
------- Comment #3 From jku 2009-09-17 05:28:34 PST (-) [reply] -------
Managed to see a 418, which is "Already exists" according to synthesis source.
I wonder if this is supposed to come to me or if synthesis should handle it?
It's not in syerror.h anyway.
------- Comment #4 From pohly 2009-09-17 06:15:17 PST (-) [reply] -------
(In reply to comment #3)
> Managed to see a 418, which is "Already exists" according to synthesis source.
Can you reproduce it?
> I wonder if this is supposed to come to me or if synthesis should handle it?
> It's not in syerror.h anyway.
Could be that the engine passes through SyncML status codes that it receives
from the server.
------- Comment #5 From jku 2009-12-10 04:30:54 PST (-) [reply] -------
Saw a sync fail consistently with 500 (DB_Fatal). Log said:
[ERROR] calendar: retrieving item: 20091210T110404Z-19227-1000-1-0@vili-rid:
Object not found
Restarting EDS fixed things.
------- Comment #6 From pohly 2009-12-16 08:22:52 PST (-) [reply] -------
I have added printing of a textual status explanation to the command line. The
output includes the distinction between errors detected locally and remotely
("local/remote") and the actual status code (because that is sometimes more
helpful than the description.
Here's an example, based on the "unexpected slow sync" error scenario where one
source runs into that problem and then the other and the whole session get
aborted automatically:
[INFO] addressbook: starting normal sync, two-way
[INFO] calendar: inactive
[ERROR] calendar: unexpected slow sync (local, status 22000)
[INFO] calendar: starting slow sync, two-way
[INFO] addressbook: preparing 1/68
[...]
[INFO] addressbook: preparing 68/68
[ERROR] Aborting because of unexpected slow sync for source(s): calendar
[INFO] Doing a slow synchronization may lead to duplicated items or
lost data when the server merges items incorrectly. Choosing
a different synchronization mode may be the better alternative.
Restart synchronization of affected source(s) with one of the
following sync modes to recover from this problem:
slow, refresh-from-server, refresh-from-client
Analyzing the current state:
syncevolution --status syncevolution_client calendar
Running with one of the three modes:
syncevolution --sync [slow|refresh-from-server|refresh-from-client]
syncevolution_client calendar
[INFO] addressbook: normal sync done unsuccessfully
[ERROR] addressbook: aborted on behalf of user (local, status 20017)
Synchronization failed, see
/home/pohly/.cache/syncevolution/syncevolution__client-2009-12-16-17-21/syncevolution-log.html
for details.
Changes applied during synchronization:
+---------------|-------ON CLIENT-------|-------ON SERVER-------|-CON-+
| | rejected / total | rejected / total | FLI |
| Source | NEW | MOD | DEL | NEW | MOD | DEL | CTS |
+---------------+-------+-------+-------+-------+-------+-------+-----+
| addressbook | 0/0 | 0/0 | 0/0 | 0/0 | 0/0 | 0/0 | 0 |
| two-way, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 68 before sync, 68 after it |
| aborted on behalf of user (local, status 20017) |
+---------------+-------+-------+-------+-------+-------+-------+-----+
| calendar | 0/0 | 0/0 | 0/0 | 0/0 | 0/0 | 0/0 | 0 |
| slow, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 13 before sync, 13 after it |
| unexpected slow sync (local, status 22000) |
+---------------+-------+-------+-------+-------+-------+-------+-----+
| start Wed Dec 16 17:21:04 2009, duration 0:04min |
| aborted on behalf of user (local, status 20017) |
+---------------+-------+-------+-------+-------+-------+-------+-----+
------- Comment #7 From jku 2010-02-09 00:57:41 PST (-) [reply] -------
Documentating this weird error as well:
When I try to sync with a bluetooth device and fail in a transport related way
I get 10500 (LOCAL_STATUS_CODE + DB_Fatal). The real problem can be e.g. the
phone being out of range or unexpectedly disconnecting (like Nokia N85 seems to
do when it encounters a difficult situation):
This is what syncevolution command line prints when phone is out of range:
[ERROR] ObexTransport: Transport Exception in sdp_source_cb
[ERROR] TransportException while sending SAN package
[ERROR] Server Alerted Sync init failed
------- Comment #8 From jku 2010-02-09 00:58:22 PST (-) [reply] -------
(In reply to comment #7)
> Documentating this weird error as well:
>
> When I try to sync with a bluetooth device and fail in a transport related way
> I get 10500 (LOCAL_STATUS_CODE + DB_Fatal).
This is via the DBus api of course.
------- Comment #9 From pohly 2010-02-09 08:14:47 PST (-) [reply] -------
(In reply to comment #7)
> Documentating this weird error as well:
>
> When I try to sync with a bluetooth device and fail in a transport related way
> I get 10500 (LOCAL_STATUS_CODE + DB_Fatal).
*All* attempts to do Bluetooth with syncevo-dbus-server will fail, see bug
#9436.
> The real problem can be e.g. the
> phone being out of range or unexpectedly disconnecting (like Nokia N85 seems to
> do when it encounters a difficult situation):
>
> This is what syncevolution command line prints when phone is out of range:
> [ERROR] ObexTransport: Transport Exception in sdp_source_cb
> [ERROR] TransportException while sending SAN package
> [ERROR] Server Alerted Sync init failed
What kind of status do you expect in this case? Does the command line record it
as expected?
------- Comment #10 From pohly 2010-03-15 03:32:45 PST (-) [reply] -------
(In reply to comment #9)
> > This is what syncevolution command line prints when phone is out of range:
> > [ERROR] ObexTransport: Transport Exception in sdp_source_cb
> > [ERROR] TransportException while sending SAN package
> > [ERROR] Server Alerted Sync init failed
>
> What kind of status do you expect in this case? Does the command line record it
> as expected?
The SAN code was changed so that a transport failure now gets reported as one,
instead of catching the transport exception and rethrowing a generic error (the
root cause for the 500 status).
------- Comment #11 From pohly 2010-03-15 03:34:46 PST (-) [reply] -------
We should move the "status to localized error description" code from the
sync-ui into a library. The syncevo-dbus-server needs this for error
notifications. Other GUIs might also benefit from it.
We can either put it into libsyncevolution or create a new utility lib. Despite
the overhead with setting that up I prefer the later. It should have a stable
ABI/API, in contrast to libsyncevolution.
--
Configure bugmail: http://bugzilla.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
12 years, 5 months
