|
Description of problem:
+++++++++++++
ref: scheduler_participantRolesEnabled
from Helge Hess
On Feb 23, 2005, at 17:33, Olivier Hallot wrote:
> I found the subject Default very interesting as it allows each appointment
> participant to individually confirm his participation on a meeting. However
> there is mention of a "Role" of participant and I can't find where to insert
> this information in the appointment.
> Have I missed something?
Yes, the feature is incomplete which is why it is disabled per default.
The roles are set if you push an iCalendar appointment into OGo, eg using Sunbird.
+++++++++++++
Version-Release number of selected component (if applicable): trunk
How reproducible: always
Steps to Reproduce:
1.
2.
3.
Actual results: There is no way to let the webUI insert the role of a participant
Expected results: A extra filed to allow to assign a role to a participant
Additional info:
related to the default
scheduler_participantRolesEnabled
|
|
------- Additional Comment
#1 From
Helge Hess on
2005-02-23 18:07
-------
|
|
I think that this is a DUP, bit I can't find the original entry.
Another thing which needs to get fixed in this context is the conflict detection
(only conflict on accepted meetings) and proposal.
|
|
------- Additional Comment
#2 From
Jens Enders on
2005-05-20 19:22
-------
|
|
Another thing which needs to get fixed in this context is,
that the color of the participants in calender views should represent the status
(like the color of the status value in the participants tab of an appointment view)
|
|
------- Additional Comment
#3 From
Jens Enders on
2005-05-21 16:22
-------
|
|
I think, it isn't necessary to popup the mail editor during change of
participants status. To me it is bothersome.
|
|
------- Additional Comment
#4 From
Helge Hess on
2005-08-01 11:52
-------
|
|
Summary:
a) enhance apt editor to allow role-selection
b) fix conflict checking to honor unconfirmed events
|
|
------- Additional Comment
#5 From
Helge Hess on
2005-08-09 18:08
-------
|
|
prepared sources, created test-tool
|
|
------- Additional Comment
#6 From
Helge Hess on
2005-08-22 16:35
-------
|
|
more source code preparations (r1217)
|
|
------- Additional Comment
#7 From
Helge Hess on
2005-08-23 17:10
-------
|
|
even more work on existing conflicts code (r1221)
|
|
------- Additional Comment
#8 From
Helge Hess on
2005-08-24 14:54
-------
|
|
iCal roles:
roleparam = "ROLE" "="
("CHAIR" ; Indicates chair of the
; calendar entity
/ "REQ-PARTICIPANT" ; Indicates a participant whose
; participation is required
/ "OPT-PARTICIPANT" ; Indicates a participant whose
; participation is optional
/ "NON-PARTICIPANT" ; Indicates a participant who is
; copied for information
; purposes only
All except non-participant will trigger the conflict panel. "Conflicting"
'opt-participant' will be shown in a different color (blue maybe).
|
|
------- Additional Comment
#9 From
Helge Hess on
2005-08-24 14:58
-------
|
|
iCal partstats:
partstatparam = "PARTSTAT" "="
("NEEDS-ACTION" ; Event needs action
/ "ACCEPTED" ; Event accepted
/ "DECLINED" ; Event declined
/ "TENTATIVE" ; Event tentatively
; accepted
/ "DELEGATED" ; Event delegated
Trigger conflict:
- accepted
- tentative (different color?)
- needs-action (different-color: blue?)
Do not trigger conflict:
- declined
- delegated
|
|
------- Additional Comment
#10 From
Helge Hess on
2005-08-24 14:59
-------
|
|
work todo:
c) implement roles/partstat in appointment search
|
|
------- Additional Comment
#11 From
Helge Hess on
2005-08-24 15:08
-------
|
|
x
|
|
------- Additional Comment
#12 From
Helge Hess on
2005-08-24 17:42
-------
|
|
The conflict command now properly deals with role/partstat (r1223). So if you
decline an appointment, it will not result in a conflict anymore.
|
|
------- Additional Comment
#14 From
Helge Hess on
2005-08-25 14:19
-------
|
|
*** Bug 329 has been marked as a duplicate of this bug. ***
|
|
------- Additional Comment
#15 From
Helge Hess on
2005-08-25 15:36
-------
|
|
Fixed a major bug in bulk-fetching of participant status fields
(participants::list command).
r1225
|
|
------- Additional Comment
#16 From
Helge Hess on
2005-08-29 12:59
-------
|
|
Conflict-Map:
CHAIR REQ-PART OPT-PART NON-PART
NEEDS-ACTION yes yes might no
ACCEPTED yes yes yes no
DECLINED no no no no
TENTATIVE yes yes yes no
DELEGATED no no no no
Obviously an OPT-PARTICIPANT also conflicts when he ACCEPT'ed the meeting. Need
to consider that.
Conflict SQL:
((part_stat='NEEDS-ACTION' AND role IN ('CHAIR', 'REQ-PARTICIPANT')) OR
(part_stat IN ('ACCEPTED', 'TENTATIVE') AND role != 'NON-PARTICIPANT'))
If we want to show "potential conflicts" for need-info/opt-part, we would also
need to fetch those (see 'might' in map)
|
|
------- Additional Comment
#17 From
Helge Hess on
2005-08-29 13:33
-------
|
|
Map with handling of records w/o role/stat setting (<null>):
Conflict-Map:
CHAIR REQ-PART OPT-PART NON-PART <NULL>
NEEDS-ACTION yes yes might no yes
<NULL> yes yes might no yes
ACCEPTED yes yes yes no yes
DECLINED no no no no no
TENTATIVE yes yes yes no yes
DELEGATED no no no no no
fixed in conflict command in r1238.
|
|
------- Additional Comment
#18 From
Helge Hess on
2005-08-29 16:32
-------
|
|
Changed appointment::conflict command to properly calculate conflict-info
records for display (r1239).
|
|
------- Additional Comment
#19 From
Helge Hess on
2005-08-29 21:24
-------
|
|
fixed an issue with changing the part status (prob introduced with the last
changes) (r1243)
|
|
------- Additional Comment
#20 From
Helge Hess on
2005-08-29 22:06
-------
|
|
localized participant role in participant-list (r1246)
|
|
------- Additional Comment
#21 From
Helge Hess on
2005-08-30 16:26
-------
|
|
added conflicts-tab to apt-viewer
fixed more issues with appointment::conflict command
r1250
|
|
------- Additional Comment
#22 From
Helge Hess on
2005-08-30 17:56
-------
|
|
r1251 shows conflict details in conflicts tab
|
|
------- Additional Comment
#23 From
Helge Hess on
2005-08-31 17:09
-------
|
|
major template cleanups in LSWAppointmentEditor (r1259)
PS: all that cleanup work which is done as part of the bugfix will make it
easier(/faster) to fix the other bugs/enhancements too.
|
|
------- Additional Comment
#24 From
Helge Hess on
2005-09-06 16:55
-------
|
|
preparations for participant selector, started reorganization of appointment
editor (r1263)
|
|
------- Additional Comment
#25 From
Olivier Hallot on
2005-09-06 20:50
-------
|
|
Helge, thanks for the effort, I am following closely this resolution.
I foresee some issues ahead, you may want to consider or maybe you already did it.
- if a participant has no OGo account (i.e. a contact), he/she will remain in
"require action" state. I think in the situation where perhaps the appt author
can change the contact state, after receiving a phone call or mail from the contact.
- cyclic appointments seems to require repeated confirmations. In that case it
may be interesting to have a "confirm/decline/tentative all" button
- the reminder could also carry the status of the participant and their role
(may need work on skyaptnotify)
I second Jan Enders demand to drop the mail on each confirmation, or put it as
an option ("Notify status to all").
Thank's again.
|
|
------- Additional Comment
#26 From
Helge Hess on
2005-09-08 17:22
-------
|
|
Reorganized appearance of appointment editor, should greatly enhance usablity
and makes space for editing participant roles.
(r1277)
|
|
------- Additional Comment
#27 From
Olivier Hallot on
2005-09-09 20:02
-------
|
|
two small glitches in the latest LSWApptEditor.wox (1277):
- the rightmost part of the screen (participant/resources...) has white
background, instead of the usual pale yellow.
- on editing an appointment with repetitions the button row get wide (six
buttons: save, save all, save & notify, delete, delete all and cancel). This
pushes the rightmost part more to the right with horizontal scrolling. Perhaps
the solution is to split the row of buttons (save, save all, save & notify) and
(delete, delete all, cancel).
Thanks
|
|
------- Additional Comment
#28 From
Helge Hess on
2005-09-16 13:09
-------
|
|
BTW: another interesting option I walked over while working on this is:
scheduler_editor_canResolveTeams
If this default is enabled, teams will be "flattened" to the contained accounts
during save. This might be relevant when using roles because that way each
participant of an event will get his own status (instead of just having one
role/status for the whole team).
|
|
------- Additional Comment
#29 From
Helge Hess on
2005-09-16 14:37
-------
|
|
Olivier: the buttons for cycles are moved to an own row. But I think I will work
a bit on that as part of bug 1508.
|
|
------- Additional Comment
#30 From
Helge Hess on
2005-09-16 15:30
-------
|
|
started attendee role selector in r1292, can be enabled by setting the
apteditor_useattendeeselector
default. Note: this is still incomplete, stay tuned.
|
|
------- Additional Comment
#31 From
Helge Hess on
2005-09-16 18:40
-------
|
|
Olivier: I don't know what you mean by:
"- the rightmost part of the screen (participant/resources...) has white
background, instead of the usual pale yellow."
Could you please attach a screenshot?
|
|
------- Additional Comment
#32 From
Helge Hess on
2005-09-16 18:53
-------
|
|
Are there suggestions for an English label of the 'non-participant' value?
Currently its kinda hard to distinguish in the editor between:
a) "do not add the search result as an attendee"
b) "add the result as a non-participant attendee" (for informational purposes)
|
|
------- Additional Comment
#33 From
Olivier Hallot on
2005-09-16 19:00
-------
|
|
Created an attachment (id=347)
screenshot of color glitch
The white background is observed on the right of the vertical bar.
Pale yellow background is on the left.
See for example, the Show companies chekbox has pale yellow background.
Template as old as yesterday.
Mozilla 1.7.8, Linux mandrake 10.1.
|
|
------- Additional Comment
#34 From
Olivier Hallot on
2005-09-16 19:05
-------
|
|
c) "just for information"
d) "for your information"
|
|
------- Additional Comment
#35 From
Helge Hess on
2005-09-16 19:07
-------
|
|
Wrt to the screenshot. Not sure I consider that a bug. The background is for
key/value (form) fields and in this case we have a plain list.
|
|
------- Additional Comment
#36 From
Helge Hess on
2005-09-16 19:08
-------
|
|
label: what about "(informational)". Would be correct?
|
|
------- Additional Comment
#37 From
Helge Hess on
2005-09-16 19:46
-------
|
|
r1293 contains more work on the attendee-selector, UI works fine. Changes are
not saved yet.
|
|
------- Additional Comment
#38 From
Helge Hess on
2005-09-19 13:16
-------
|
|
r1299 now properly loads roles from the DB and the attendee editor works for
creating/editing apts. The only missing thing is saving the roles now.
|
|
------- Additional Comment
#39 From
Helge Hess on
2005-09-19 16:38
-------
|
|
r1303 can now save the role. This needs _heavy_ testing (creating / changing
appointments).
Next step is to check the apt proposal, if this works, we are done.
|
|
------- Additional Comment
#40 From
Olivier Hallot on
2005-09-19 17:36
-------
|
|
I'm not sure I get the way to input the role in the webUI. I am at 1303 and
LSWAppointmentEditor.wox is 1299.
Inspecting the wox file I see
session.userDefaults.apteditor_useattendeeselector.boolValue
Is this a default? something that should be set in the CAlendar preferences?
Thanks
|
|
------- Additional Comment
#41 From
Helge Hess on
2005-09-19 17:48
-------
|
|
Yes, its a default and can be set in the shell using the Defaults tool. No, it
isn't configurable for the user.
|
|
------- Additional Comment
#42 From
Helge Hess on
2005-09-19 18:27
-------
|
|
I've submitted bug 1573 for the proposal implementation, this would require a
major rewrite of the proposal-command :-|
So closing this bug with the following features:
- can edit participant role in the appointment editor
- conflict checks properly handle role and participant status
- new conflicts tab which shows appointments using the same resources
- highly improved apt-editor UI
- huge number of code improvements in the scheduler subsystem
Please open new bugs for enhancements / change requests, only reopen this one if
the functionality as described doesn't work.
=> QA
|
|
------- Additional Comment
#43 From
Olivier Hallot on
2005-09-20 21:42
-------
|
|
The print function is not working as before.
Clicking the print button on a appointment view, a new browser window opens with
the same content and layout as the main screen. The browser print command is not
activated.
|
|
------- Additional Comment
#44 From
Sebastian Reitenbach on
2005-09-21 06:36
-------
|
|
Hi,
I can confirm this printing issue on my installations.
|
|
------- Additional Comment
#45 From
Helge Hess on
2005-09-27 15:02
-------
|
|
And how is this related to the bugreport called "implement role ..."? Please
open new bug reports for new bugs!
|
|
------- Additional Comment
#46 From
Helge Hess on
2005-09-27 15:06
-------
|
|
fixed print issue in r1331, nothin' to do with this bug report though ...
|
|
------- Additional Comment
#47 From
Helge Hess on
2005-10-05 19:14
-------
|
|
Willie says:
When creating an appointment, I have the option of specifying "no
participant" for any person in the list of participants. I might do
this if I were managing the calendar for another user (mark myself as a
non-participant) or if I wanted to provide an information only copy to
an OGo user with no provision that [s]he should actually attend the
event. In both cases:
1) The conflict checker should not flag a conflict with the "no
participant" person and
2) The appointment should not be displayed as an active event for the
user who is a "no participant" person
In short, the conflict checker should ignore users with the "no
participant" role ...
|
|
------- Additional Comment
#48 From
Helge Hess on
2005-10-05 19:29
-------
|
|
The conflict check in r1397 is a _bit_ smarter and checks the role for
NON-PARTICIPANT. This seems to work just fine for create/save an appointment.
But: this is a really difficult topic to solve generically because the conflict
checker doesn't always have the role information due to internal design (it will
report conflicts in such cases and not if it has the info).
|
|
------- Additional Comment
#49 From
Helge Hess on
2005-10-05 19:30
-------
|
|
=>QA
|
|
------- Additional Comment
#50 From
Helge Hess on
2005-10-05 19:30
-------
|
|
Not sure what you mean by this:
---
2) The appointment should not be displayed as an active event for the
user who is a "no participant" person
---
Whats an "active event"?
|
|
------- Additional Comment
#51 From
Willie Shank on
2005-10-05 19:45
-------
|
|
I think of anything that is displayed on the calendar view as "active". The
meaning was, don't display an appointment on my calendar view if I have a "no
participant" role. If I'm not a participant, it should not display on my
calendar -- at least that's my logic.
|
|
------- Additional Comment
#52 From
Helge Hess on
2005-10-05 19:49
-------
|
|
Well, but this is the rational of using the non-participant feature :-) If you
don't want to have this additional information popup, the apt creator just
doesn't need to add the user as a participant. (and if the non-participant is
annoyed, he can still remove himself from the apt)
|
|
------- Additional Comment
#53 From
Willie Shank on
2005-10-05 19:56
-------
|
|
OK -- my intention was to present it to users in that manner until I also
encountered the conflict issue. At that point, I elected to include both comments.
>> the apt creator just doesn't need to add the user as a participant
But isn't that what he's doing by saying this person is not a participant?
So then, what *is* the purpose of the "no participant" role???
|
|
------- Additional Comment
#54 From
Frank Reppin on
2005-10-06 13:52
-------
|
|
Tested the 'smarter' logic behind the conflict checker when trying to
collide an appt. with a non-participant member:
save/create -> works fine - no conflict panel appears
move -> works fine as well (no conflict panel appears)
|
|
------- Additional Comment
#55 From
Helge Hess on
2005-10-06 14:10
-------
|
|
Willie:
The non-participant role is to attach "relevant" accounts to events which are
not attendees. That is, the event is considered important for them and it should
up in their "calendar". This may or may not be useful for you :-)
If you do not want to attach a certain contact, use the "remove" field in the
popup of the apt editor.
Technically this was added to have complete support for the iCalendar standard
which includes this role (so we must be able to show/edit/process this for
better client compability).
Another side-effect which might be useful (or not) is that non-participants have
implicit read-access. So you can mark an event private, but make it available to
selected accounts (w/o marking them as attendees).
Hope this clears things up. I think it does work as intended.
|
|
------- Additional Comment
#56 From
Helge Hess on
2005-12-22 15:46
-------
|
|
I assume we can close this bug as done? Please reopen if there are issues left.
|
|
