So you'd be able to invite everyone in a comm to an event interesting idea, I haven't thought about this particular feature - inviting to an event - but it seems to be a valuable feature or invite an on-fly-list, or a custom access group that you have set up? Or would each community have a calendar, and members would see community events on their calendar? Every calendar would have an administrator, by default the person who created it. She/he would have a possibility to choose if the whole calendar would be private, seen by particular people, seen by particular group(s).
In parallel, a single user would have an ability to display single calendars, but also combine chosen calendars event in a new view - so that she/he could have a more complex vision of upcoming events as well as better chances not to miss the event. Nonetheless, as I've mentioned, the possibility to invite people for not only a calendar, but also single event seems very interesting and I'd really like to add it to calendar features requirements.
If every calendar has a list of people with defined rights, would this be updated automatically if you give someone new permissions in the community (e.g. posting access) or would it be separate? I think the following proposition could be discussed: Situation 1: If it would be a calendar with dw_dev events, I suppose there would be no need to performing special actions for adding calendar readers in other way than when a person becomes a dw_dev member (however, before adding the dw_dev calendar to the person's calendars view, this person should be asked if she/he is willing to). The rights set to the group would concern the whole group as well. When a person would resign from dw_dev membership, the dw_dev events shouldn't appear in the person's calendar, I suppose; etc.
Situation 2: If, lets say, I want to share my calendar with my best friend and show (and not let to edit) my plan to my school mate, I'd send personal invitation to those people, defining their rights one by one.
Situation 3: However, there may probably happen situations, when we would not like only particular people from the group to see the calendar (just as hes Denise mentioned - e.g. when we prepare a secret birthday party. This may be solved by adding people individually by the calendar creator (or by people who would have rights to do so). [ Therefore implementation, in order to determine user's rights to calendar, should primary consider if a person is added as a single account, and if not - as a group member. ]
Summing this point up: The calendar's creator (who automatically becomes it's administrator) while creating a calendar will have a possibility to: - set the calendar's visibility - choose people, groups who would be invited to have an access to the calendar - define the access level (the rights) for chosen people (one by one) and groups (group members have by default the same rights).
The whole process could perform in the following way:
I think that if a group would be given an access to the calendar, becoming a member of the group automatically gives the particular (defined by calendar's administrator) rights to the calendar.
I, naturally, welcome every suggestion that would lead to better solution. I think, this case may evolve depending on Users (this means ours:P) demands. And one more remark: I personally think, that there should be possibility of choice in the security field, however too many options may lead to verbosity and make choice not intelligible. This, in turn, may cause mistakes in the security area, which - as I've learned - is highly undesirable in Dreamwidth. This means that I'd need to ask for help when defining a final configuration panel: there may be important issues that I may not notice or instead of brevity, I'd achieve too much complexity.
Generally, when working on project, I'd like to create a suggestions thread, where I would ask Dreamwidth members about Their opinion and would be very glad to read about their own ideas or needs.
Would "editing the calendar" be a new level between posting access and moderator? The privileges is the another important issue (as it concerns security). This again would have to be discussed among Dw community. As for now I propose the following levels: - calendar administrator (who by deault would be the calendar's creator) - deciding about the calendar's access - managing (creating & editing & deleting) events - viewing events
Above all - this questions You made are just what I would appreciate when working on project (thanks). They show me aspects that I may not identify on my own.
Re: Group calendar events
interesting idea, I haven't thought about this particular feature - inviting to an event - but it seems to be a valuable feature
or invite an on-fly-list, or a custom access group that you have set up? Or would each community have a calendar, and members would see community events on their calendar?
Every calendar would have an administrator, by default the person who created it. She/he would have a possibility to choose if the whole calendar would be private, seen by particular people, seen by particular group(s).
In parallel, a single user would have an ability to display single calendars, but also combine chosen calendars event in a new view - so that she/he could have a more complex vision of upcoming events as well as better chances not to miss the event.
Nonetheless, as I've mentioned, the possibility to invite people for not only a calendar, but also single event seems very interesting and I'd really like to add it to calendar features requirements.
If every calendar has a list of people with defined rights, would this be updated automatically if you give someone new permissions in the community (e.g. posting access) or would it be separate?
I think the following proposition could be discussed:
Situation 1:
If it would be a calendar with dw_dev events, I suppose there would be no need to performing special actions for adding calendar readers in other way than when a person becomes a dw_dev member (however, before adding the dw_dev calendar to the person's calendars view, this person should be asked if she/he is willing to). The rights set to the group would concern the whole group as well. When a person would resign from dw_dev membership, the dw_dev events shouldn't appear in the person's calendar, I suppose; etc.
Situation 2:
If, lets say, I want to share my calendar with my best friend and show (and not let to edit) my plan to my school mate, I'd send personal invitation to those people, defining their rights one by one.
Situation 3:
However, there may probably happen situations, when we would not like only particular people from the group to see the calendar (just as hes Denise mentioned - e.g. when we prepare a secret birthday party. This may be solved by adding people individually by the calendar creator (or by people who would have rights to do so).
[ Therefore implementation, in order to determine user's rights to calendar, should primary consider if a person is added as a single account, and if not - as a group member. ]
Summing this point up:
The calendar's creator (who automatically becomes it's administrator) while creating a calendar will have a possibility to:
- set the calendar's visibility - choose people, groups who would be invited to have an access to the calendar
- define the access level (the rights) for chosen people (one by one) and groups (group members have by default the same rights).
The whole process could perform in the following way:
I think that if a group would be given an access to the calendar, becoming a member of the group automatically gives the particular (defined by calendar's administrator) rights to the calendar.
I, naturally, welcome every suggestion that would lead to better solution. I think, this case may evolve depending on Users (this means ours:P) demands.
And one more remark: I personally think, that there should be possibility of choice in the security field, however too many options may lead to verbosity and make choice not intelligible. This, in turn, may cause mistakes in the security area, which - as I've learned - is highly undesirable in Dreamwidth. This means that I'd need to ask for help when defining a final configuration panel: there may be important issues that I may not notice or instead of brevity, I'd achieve too much complexity.
Generally, when working on project, I'd like to create a suggestions thread, where I would ask Dreamwidth members about Their opinion and would be very glad to read about their own ideas or needs.
Would "editing the calendar" be a new level between posting access and moderator?
The privileges is the another important issue (as it concerns security). This again would have to be discussed among Dw community. As for now I propose the following levels:
- calendar administrator (who by deault would be the calendar's creator) - deciding about the calendar's access
- managing (creating & editing & deleting) events
- viewing events
Above all - this questions You made are just what I would appreciate when working on project (thanks). They show me aspects that I may not identify on my own.