MoodleDocs - User contributions [en]

Talk:Process

2010-12-16T23:55:16Z

Moerderin: /* create pull request in tracker */

I think 'User' should be described as both 'finding issues' and 'suggesting improvements' for Moodle, even if the detail of how things are implemented are left for the Product Owner. Just thinking that a good chunk of the things I add to the Tracker are suggestions for improvement rather than 'issues' as such and that we should promote this idea as a general rule - maybe :)

:I agree with Mark. Bug tracker should be used for actual bugs. Discussion about future roadmaps, enhcnements and improvements is a separate matter, and in actual fact it is hard to engage in this. I don't have an answer at the moment. Maybe a place to discuss, and notification of when discussions have heated up (like specs are being prepared and a new roadmap developed for a component) ie owners manage the discussion, but there is a clear place to go to engage, some indication of timelines etc. --[[User:Derek Chirnside|Derek Chirnside]] 19:39, 25 November 2010 (UTC)

Well, "issues" there was meant to cover "bugs" and "suggestions", as the tracker does both. I'll make it more explicit though. [[User:Martin Dougiamas|Martin Dougiamas]] 10:12, 30 November 2010 (UTC)

OK - I could live with this. But I still prefer this clearer distinction as suggested by Mark:

===User role===

# Uses Moodle
# Finds issues/bugs (report in tracker)
# Suggests improvements (report in tracker)

Question: is there a way in the tracker to keep issues in two lists: bugs and suggestions? Maybe even like Google: you can suggest anything, but at any given time there are a few suggestions up for vote? In Moodle, you can discuss anything, but someone is highlighting at any given time a few topics for focused discussions. On reflection the answer may be No - on this basis I am back to my original suggestion.

A bug is a bug - it is not working as we know it should. A suggestion for an enhancement is partly an invitation to dialogue, vote. Voting for bugs is silly - all bugs need fixing, and priorities are best (IMO) determined centrally. So:

#Uses Moodle
#Finds and reports bugs (use tracker)
#Suggests improvements (use tracker)
#Takes part in dialogue around suggested improvements

[[User:Derek Chirnside|Derek Chirnside]] 06:18, 4 December 2010 (UTC)

:Derek, thanks for your comments. Regarding a way in the tracker to keep issues in two lists: bugs and suggestions, when you create an issue you have a choice of issue types - bug, new feature, task and improvement. Thus, a search for all new features and improvements should generate a list of suggestions. --[[User:Helen Foster|Helen Foster]] 14:31, 4 December 2010 (UTC)

== Backlog naming ==

Regarding the latest change about naming backlog versions with "STABLEBACKLOG/DEVBACKLOG", I'd recommend to use instead something like: "1.9.x backlog/2.0.x backlog/2.1.x backlog" because:

# It saves us to move things when a new major release happens (so it won't be necessary to move all the DEVBACKLOG => STABLEBACKLOG".
# It supports '''multiple''' stable branches, like we have now (1.9.x, 2.0.x...)
# It respects the format used by both the Affected Branches and Fixed Branches custom fields that are really useful for a lot of filters.

Ciao, [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 23:33, 6 December 2010 (UTC) :-)

:Addenda: Finally it has been decided to go to 2 backlogs only (stable/dev). Fair enough so developer (team) will look to the real branches were solution needs to be implemented. [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 10:23, 9 December 2010 (UTC)

==This does not look like scrum to me at all==

I think we need a certified scrum master. This proposal IMHO seems to break nearly all the good Scrum practises described in books.

Ciao, [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] 10:03, 9 December 2010 (UTC)

:Agree! some points (see point 3 especially, both in STABLE/DEV teams, break the thing. It's (scrum, by team) master responsibility to discuss with product owner, not team itself! Isolation is a MUST.

: Ciao, [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 10:12, 9 December 2010 (UTC)

----

== If the issue is a bug in the current stable version requiring database changes, assign "Fix version" to DEVBACKLOG ==

Hmm, maybe this should be governed up by bug severity too? You, sure, aren't going to say that every bug requiring DB update, however severe it is, should be left up to the next major release? --[[User:Oleg Sychev|Oleg Sychev]] 14:51, 9 December 2010 (UTC)

I understand the idea of pulling from the items with the highest priority; however, how are we going to determine that priority. We have issue severity which has traditionally been seen as a priority indicator but we also have the number of votes. I am curious when paper cuts will be taken care of. These smaller issues can impact the user experience. I suspect in an ideal world, all the major issues will be dealt with but occasionally some simple fixes come along with patches in the tracker and it would be good to get those applied. Peace - Anthony

: Well, in practice I expect people will choose items based on a cost/benefit analysis of fixing them - just like they always have in the past.--[[User:Tim Hunt|Tim Hunt]] 18:14, 16 December 2010 (UTC)

== Suggested changes for "External Developers" ==
I had a really good conversation with David (He posted a screenshot that maybe does a better job of explaining what is described below: http://picasaweb.google.com/david.mudrak/Moodle#5551427587739059122), and we discussed one possible suggested workflow external developers can use if they choose to use their own GIT repo. Here's how it would break down:

=== Creating repo ===
==== Branch off MOODLE_20_STABLE (ie: UCLA_TRUNK) ====
$ git --bare fetch git://git.moodle.org/moodle.git MOODLE_20_STABLE:MOODLE_20_STABLE
$ git checkout -b UCLA_TRUNK origin/MOODLE_20_STABLE

==== commit customizations into branch ====
$ ... (hack something, git add, git commit)
$ git push

=== Contributing back ===
==== Create another branch off MOODLE_20_STABLE (ie: COOL_NEW_FEATURE) ====
$ git --bare fetch git://git.moodle.org/moodle.git MOODLE_20_STABLE:MOODLE_20_STABLE
$ git checkout -b COOL_NEW_FEATURE origin/MOODLE_20_STABLE

==== git cherry-pick to selectively pick commits from UCLA_TRUNK to merge into COOL_NEW_FEATURE ====
$ git cherry-pick 7300a6130d9447e18a931e898b64eefedea19544

==== publish branch COOL_NEW_FEATURE ====
??

==== create pull request in tracker ====
http://tracker.moodle.org/browse/PULL-18

If accepted, it becomes part of core moodle

=== Updating to next version of Moodle ===
$ git pull

Talk:Process

2010-12-16T23:47:49Z

Moerderin: /* Updating to next version of Moodle */

I think 'User' should be described as both 'finding issues' and 'suggesting improvements' for Moodle, even if the detail of how things are implemented are left for the Product Owner. Just thinking that a good chunk of the things I add to the Tracker are suggestions for improvement rather than 'issues' as such and that we should promote this idea as a general rule - maybe :)

:I agree with Mark. Bug tracker should be used for actual bugs. Discussion about future roadmaps, enhcnements and improvements is a separate matter, and in actual fact it is hard to engage in this. I don't have an answer at the moment. Maybe a place to discuss, and notification of when discussions have heated up (like specs are being prepared and a new roadmap developed for a component) ie owners manage the discussion, but there is a clear place to go to engage, some indication of timelines etc. --[[User:Derek Chirnside|Derek Chirnside]] 19:39, 25 November 2010 (UTC)

Well, "issues" there was meant to cover "bugs" and "suggestions", as the tracker does both. I'll make it more explicit though. [[User:Martin Dougiamas|Martin Dougiamas]] 10:12, 30 November 2010 (UTC)

OK - I could live with this. But I still prefer this clearer distinction as suggested by Mark:

===User role===

# Uses Moodle
# Finds issues/bugs (report in tracker)
# Suggests improvements (report in tracker)

Question: is there a way in the tracker to keep issues in two lists: bugs and suggestions? Maybe even like Google: you can suggest anything, but at any given time there are a few suggestions up for vote? In Moodle, you can discuss anything, but someone is highlighting at any given time a few topics for focused discussions. On reflection the answer may be No - on this basis I am back to my original suggestion.

A bug is a bug - it is not working as we know it should. A suggestion for an enhancement is partly an invitation to dialogue, vote. Voting for bugs is silly - all bugs need fixing, and priorities are best (IMO) determined centrally. So:

#Uses Moodle
#Finds and reports bugs (use tracker)
#Suggests improvements (use tracker)
#Takes part in dialogue around suggested improvements

[[User:Derek Chirnside|Derek Chirnside]] 06:18, 4 December 2010 (UTC)

:Derek, thanks for your comments. Regarding a way in the tracker to keep issues in two lists: bugs and suggestions, when you create an issue you have a choice of issue types - bug, new feature, task and improvement. Thus, a search for all new features and improvements should generate a list of suggestions. --[[User:Helen Foster|Helen Foster]] 14:31, 4 December 2010 (UTC)

== Backlog naming ==

Regarding the latest change about naming backlog versions with "STABLEBACKLOG/DEVBACKLOG", I'd recommend to use instead something like: "1.9.x backlog/2.0.x backlog/2.1.x backlog" because:

# It saves us to move things when a new major release happens (so it won't be necessary to move all the DEVBACKLOG => STABLEBACKLOG".
# It supports '''multiple''' stable branches, like we have now (1.9.x, 2.0.x...)
# It respects the format used by both the Affected Branches and Fixed Branches custom fields that are really useful for a lot of filters.

Ciao, [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 23:33, 6 December 2010 (UTC) :-)

:Addenda: Finally it has been decided to go to 2 backlogs only (stable/dev). Fair enough so developer (team) will look to the real branches were solution needs to be implemented. [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 10:23, 9 December 2010 (UTC)

==This does not look like scrum to me at all==

I think we need a certified scrum master. This proposal IMHO seems to break nearly all the good Scrum practises described in books.

Ciao, [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] 10:03, 9 December 2010 (UTC)

:Agree! some points (see point 3 especially, both in STABLE/DEV teams, break the thing. It's (scrum, by team) master responsibility to discuss with product owner, not team itself! Isolation is a MUST.

: Ciao, [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 10:12, 9 December 2010 (UTC)

----

== If the issue is a bug in the current stable version requiring database changes, assign "Fix version" to DEVBACKLOG ==

Hmm, maybe this should be governed up by bug severity too? You, sure, aren't going to say that every bug requiring DB update, however severe it is, should be left up to the next major release? --[[User:Oleg Sychev|Oleg Sychev]] 14:51, 9 December 2010 (UTC)

I understand the idea of pulling from the items with the highest priority; however, how are we going to determine that priority. We have issue severity which has traditionally been seen as a priority indicator but we also have the number of votes. I am curious when paper cuts will be taken care of. These smaller issues can impact the user experience. I suspect in an ideal world, all the major issues will be dealt with but occasionally some simple fixes come along with patches in the tracker and it would be good to get those applied. Peace - Anthony

: Well, in practice I expect people will choose items based on a cost/benefit analysis of fixing them - just like they always have in the past.--[[User:Tim Hunt|Tim Hunt]] 18:14, 16 December 2010 (UTC)

== Suggested changes for "External Developers" ==
I had a really good conversation with David (He posted a screenshot that maybe does a better job of explaining what is described below: http://picasaweb.google.com/david.mudrak/Moodle#5551427587739059122), and we discussed one possible suggested workflow external developers can use if they choose to use their own GIT repo. Here's how it would break down:

=== Creating repo ===
==== Branch off MOODLE_20_STABLE (ie: UCLA_TRUNK) ====
$ git --bare fetch git://git.moodle.org/moodle.git MOODLE_20_STABLE:MOODLE_20_STABLE
$ git checkout -b UCLA_TRUNK origin/MOODLE_20_STABLE

==== commit customizations into branch ====
$ ... (hack something, git add, git commit)
$ git push

=== Contributing back ===
==== Create another branch off MOODLE_20_STABLE (ie: COOL_NEW_FEATURE) ====
$ git --bare fetch git://git.moodle.org/moodle.git MOODLE_20_STABLE:MOODLE_20_STABLE
$ git checkout -b COOL_NEW_FEATURE origin/MOODLE_20_STABLE

==== git cherry-pick to selectively pick commits from UCLA_TRUNK to merge into COOL_NEW_FEATURE ====
$ git cherry-pick 7300a6130d9447e18a931e898b64eefedea19544

==== publish branch COOL_NEW_FEATURE ====
??

==== create pull request in tracker ====
http://tracker.moodle.org/secure/CreateIssue!default.jspa (Is this the right place?)

If accepted, it becomes part of core moodle

=== Updating to next version of Moodle ===
$ git pull

Talk:Process

2010-12-16T23:47:40Z

Moerderin: /* git cherry-pick to selectively pick commits from UCLA_TRUNK to merge into COOL_NEW_FEATURE */

I think 'User' should be described as both 'finding issues' and 'suggesting improvements' for Moodle, even if the detail of how things are implemented are left for the Product Owner. Just thinking that a good chunk of the things I add to the Tracker are suggestions for improvement rather than 'issues' as such and that we should promote this idea as a general rule - maybe :)

:I agree with Mark. Bug tracker should be used for actual bugs. Discussion about future roadmaps, enhcnements and improvements is a separate matter, and in actual fact it is hard to engage in this. I don't have an answer at the moment. Maybe a place to discuss, and notification of when discussions have heated up (like specs are being prepared and a new roadmap developed for a component) ie owners manage the discussion, but there is a clear place to go to engage, some indication of timelines etc. --[[User:Derek Chirnside|Derek Chirnside]] 19:39, 25 November 2010 (UTC)

Well, "issues" there was meant to cover "bugs" and "suggestions", as the tracker does both. I'll make it more explicit though. [[User:Martin Dougiamas|Martin Dougiamas]] 10:12, 30 November 2010 (UTC)

OK - I could live with this. But I still prefer this clearer distinction as suggested by Mark:

===User role===

# Uses Moodle
# Finds issues/bugs (report in tracker)
# Suggests improvements (report in tracker)

Question: is there a way in the tracker to keep issues in two lists: bugs and suggestions? Maybe even like Google: you can suggest anything, but at any given time there are a few suggestions up for vote? In Moodle, you can discuss anything, but someone is highlighting at any given time a few topics for focused discussions. On reflection the answer may be No - on this basis I am back to my original suggestion.

A bug is a bug - it is not working as we know it should. A suggestion for an enhancement is partly an invitation to dialogue, vote. Voting for bugs is silly - all bugs need fixing, and priorities are best (IMO) determined centrally. So:

#Uses Moodle
#Finds and reports bugs (use tracker)
#Suggests improvements (use tracker)
#Takes part in dialogue around suggested improvements

[[User:Derek Chirnside|Derek Chirnside]] 06:18, 4 December 2010 (UTC)

:Derek, thanks for your comments. Regarding a way in the tracker to keep issues in two lists: bugs and suggestions, when you create an issue you have a choice of issue types - bug, new feature, task and improvement. Thus, a search for all new features and improvements should generate a list of suggestions. --[[User:Helen Foster|Helen Foster]] 14:31, 4 December 2010 (UTC)

== Backlog naming ==

Regarding the latest change about naming backlog versions with "STABLEBACKLOG/DEVBACKLOG", I'd recommend to use instead something like: "1.9.x backlog/2.0.x backlog/2.1.x backlog" because:

# It saves us to move things when a new major release happens (so it won't be necessary to move all the DEVBACKLOG => STABLEBACKLOG".
# It supports '''multiple''' stable branches, like we have now (1.9.x, 2.0.x...)
# It respects the format used by both the Affected Branches and Fixed Branches custom fields that are really useful for a lot of filters.

Ciao, [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 23:33, 6 December 2010 (UTC) :-)

:Addenda: Finally it has been decided to go to 2 backlogs only (stable/dev). Fair enough so developer (team) will look to the real branches were solution needs to be implemented. [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 10:23, 9 December 2010 (UTC)

==This does not look like scrum to me at all==

I think we need a certified scrum master. This proposal IMHO seems to break nearly all the good Scrum practises described in books.

Ciao, [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] 10:03, 9 December 2010 (UTC)

:Agree! some points (see point 3 especially, both in STABLE/DEV teams, break the thing. It's (scrum, by team) master responsibility to discuss with product owner, not team itself! Isolation is a MUST.

: Ciao, [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 10:12, 9 December 2010 (UTC)

----

== If the issue is a bug in the current stable version requiring database changes, assign "Fix version" to DEVBACKLOG ==

Hmm, maybe this should be governed up by bug severity too? You, sure, aren't going to say that every bug requiring DB update, however severe it is, should be left up to the next major release? --[[User:Oleg Sychev|Oleg Sychev]] 14:51, 9 December 2010 (UTC)

I understand the idea of pulling from the items with the highest priority; however, how are we going to determine that priority. We have issue severity which has traditionally been seen as a priority indicator but we also have the number of votes. I am curious when paper cuts will be taken care of. These smaller issues can impact the user experience. I suspect in an ideal world, all the major issues will be dealt with but occasionally some simple fixes come along with patches in the tracker and it would be good to get those applied. Peace - Anthony

: Well, in practice I expect people will choose items based on a cost/benefit analysis of fixing them - just like they always have in the past.--[[User:Tim Hunt|Tim Hunt]] 18:14, 16 December 2010 (UTC)

== Suggested changes for "External Developers" ==
I had a really good conversation with David (He posted a screenshot that maybe does a better job of explaining what is described below: http://picasaweb.google.com/david.mudrak/Moodle#5551427587739059122), and we discussed one possible suggested workflow external developers can use if they choose to use their own GIT repo. Here's how it would break down:

=== Creating repo ===
==== Branch off MOODLE_20_STABLE (ie: UCLA_TRUNK) ====
$ git --bare fetch git://git.moodle.org/moodle.git MOODLE_20_STABLE:MOODLE_20_STABLE
$ git checkout -b UCLA_TRUNK origin/MOODLE_20_STABLE

==== commit customizations into branch ====
$ ... (hack something, git add, git commit)
$ git push

=== Contributing back ===
==== Create another branch off MOODLE_20_STABLE (ie: COOL_NEW_FEATURE) ====
$ git --bare fetch git://git.moodle.org/moodle.git MOODLE_20_STABLE:MOODLE_20_STABLE
$ git checkout -b COOL_NEW_FEATURE origin/MOODLE_20_STABLE

==== git cherry-pick to selectively pick commits from UCLA_TRUNK to merge into COOL_NEW_FEATURE ====
$ git cherry-pick 7300a6130d9447e18a931e898b64eefedea19544

==== publish branch COOL_NEW_FEATURE ====
??

==== create pull request in tracker ====
http://tracker.moodle.org/secure/CreateIssue!default.jspa (Is this the right place?)

If accepted, it becomes part of core moodle

=== Updating to next version of Moodle ===
git pull

Talk:Process

2010-12-16T23:47:33Z

Moerderin: /* git cherry-pick to selectively pick commits from UCLA_TRUNK to merge into COOL_NEW_FEATURE */

I think 'User' should be described as both 'finding issues' and 'suggesting improvements' for Moodle, even if the detail of how things are implemented are left for the Product Owner. Just thinking that a good chunk of the things I add to the Tracker are suggestions for improvement rather than 'issues' as such and that we should promote this idea as a general rule - maybe :)

:I agree with Mark. Bug tracker should be used for actual bugs. Discussion about future roadmaps, enhcnements and improvements is a separate matter, and in actual fact it is hard to engage in this. I don't have an answer at the moment. Maybe a place to discuss, and notification of when discussions have heated up (like specs are being prepared and a new roadmap developed for a component) ie owners manage the discussion, but there is a clear place to go to engage, some indication of timelines etc. --[[User:Derek Chirnside|Derek Chirnside]] 19:39, 25 November 2010 (UTC)

Well, "issues" there was meant to cover "bugs" and "suggestions", as the tracker does both. I'll make it more explicit though. [[User:Martin Dougiamas|Martin Dougiamas]] 10:12, 30 November 2010 (UTC)

OK - I could live with this. But I still prefer this clearer distinction as suggested by Mark:

===User role===

# Uses Moodle
# Finds issues/bugs (report in tracker)
# Suggests improvements (report in tracker)

Question: is there a way in the tracker to keep issues in two lists: bugs and suggestions? Maybe even like Google: you can suggest anything, but at any given time there are a few suggestions up for vote? In Moodle, you can discuss anything, but someone is highlighting at any given time a few topics for focused discussions. On reflection the answer may be No - on this basis I am back to my original suggestion.

A bug is a bug - it is not working as we know it should. A suggestion for an enhancement is partly an invitation to dialogue, vote. Voting for bugs is silly - all bugs need fixing, and priorities are best (IMO) determined centrally. So:

#Uses Moodle
#Finds and reports bugs (use tracker)
#Suggests improvements (use tracker)
#Takes part in dialogue around suggested improvements

[[User:Derek Chirnside|Derek Chirnside]] 06:18, 4 December 2010 (UTC)

:Derek, thanks for your comments. Regarding a way in the tracker to keep issues in two lists: bugs and suggestions, when you create an issue you have a choice of issue types - bug, new feature, task and improvement. Thus, a search for all new features and improvements should generate a list of suggestions. --[[User:Helen Foster|Helen Foster]] 14:31, 4 December 2010 (UTC)

== Backlog naming ==

Regarding the latest change about naming backlog versions with "STABLEBACKLOG/DEVBACKLOG", I'd recommend to use instead something like: "1.9.x backlog/2.0.x backlog/2.1.x backlog" because:

# It saves us to move things when a new major release happens (so it won't be necessary to move all the DEVBACKLOG => STABLEBACKLOG".
# It supports '''multiple''' stable branches, like we have now (1.9.x, 2.0.x...)
# It respects the format used by both the Affected Branches and Fixed Branches custom fields that are really useful for a lot of filters.

Ciao, [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 23:33, 6 December 2010 (UTC) :-)

:Addenda: Finally it has been decided to go to 2 backlogs only (stable/dev). Fair enough so developer (team) will look to the real branches were solution needs to be implemented. [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 10:23, 9 December 2010 (UTC)

==This does not look like scrum to me at all==

I think we need a certified scrum master. This proposal IMHO seems to break nearly all the good Scrum practises described in books.

Ciao, [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] 10:03, 9 December 2010 (UTC)

:Agree! some points (see point 3 especially, both in STABLE/DEV teams, break the thing. It's (scrum, by team) master responsibility to discuss with product owner, not team itself! Isolation is a MUST.

: Ciao, [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 10:12, 9 December 2010 (UTC)

----

== If the issue is a bug in the current stable version requiring database changes, assign "Fix version" to DEVBACKLOG ==

Hmm, maybe this should be governed up by bug severity too? You, sure, aren't going to say that every bug requiring DB update, however severe it is, should be left up to the next major release? --[[User:Oleg Sychev|Oleg Sychev]] 14:51, 9 December 2010 (UTC)

I understand the idea of pulling from the items with the highest priority; however, how are we going to determine that priority. We have issue severity which has traditionally been seen as a priority indicator but we also have the number of votes. I am curious when paper cuts will be taken care of. These smaller issues can impact the user experience. I suspect in an ideal world, all the major issues will be dealt with but occasionally some simple fixes come along with patches in the tracker and it would be good to get those applied. Peace - Anthony

: Well, in practice I expect people will choose items based on a cost/benefit analysis of fixing them - just like they always have in the past.--[[User:Tim Hunt|Tim Hunt]] 18:14, 16 December 2010 (UTC)

== Suggested changes for "External Developers" ==
I had a really good conversation with David (He posted a screenshot that maybe does a better job of explaining what is described below: http://picasaweb.google.com/david.mudrak/Moodle#5551427587739059122), and we discussed one possible suggested workflow external developers can use if they choose to use their own GIT repo. Here's how it would break down:

=== Creating repo ===
==== Branch off MOODLE_20_STABLE (ie: UCLA_TRUNK) ====
$ git --bare fetch git://git.moodle.org/moodle.git MOODLE_20_STABLE:MOODLE_20_STABLE
$ git checkout -b UCLA_TRUNK origin/MOODLE_20_STABLE

==== commit customizations into branch ====
$ ... (hack something, git add, git commit)
$ git push

=== Contributing back ===
==== Create another branch off MOODLE_20_STABLE (ie: COOL_NEW_FEATURE) ====
$ git --bare fetch git://git.moodle.org/moodle.git MOODLE_20_STABLE:MOODLE_20_STABLE
$ git checkout -b COOL_NEW_FEATURE origin/MOODLE_20_STABLE

==== git cherry-pick to selectively pick commits from UCLA_TRUNK to merge into COOL_NEW_FEATURE ====
$git cherry-pick 7300a6130d9447e18a931e898b64eefedea19544

==== publish branch COOL_NEW_FEATURE ====
??

==== create pull request in tracker ====
http://tracker.moodle.org/secure/CreateIssue!default.jspa (Is this the right place?)

If accepted, it becomes part of core moodle

=== Updating to next version of Moodle ===
git pull

Talk:Process

2010-12-16T23:47:20Z

Moerderin: /* commit customizations into branch */

I think 'User' should be described as both 'finding issues' and 'suggesting improvements' for Moodle, even if the detail of how things are implemented are left for the Product Owner. Just thinking that a good chunk of the things I add to the Tracker are suggestions for improvement rather than 'issues' as such and that we should promote this idea as a general rule - maybe :)

:I agree with Mark. Bug tracker should be used for actual bugs. Discussion about future roadmaps, enhcnements and improvements is a separate matter, and in actual fact it is hard to engage in this. I don't have an answer at the moment. Maybe a place to discuss, and notification of when discussions have heated up (like specs are being prepared and a new roadmap developed for a component) ie owners manage the discussion, but there is a clear place to go to engage, some indication of timelines etc. --[[User:Derek Chirnside|Derek Chirnside]] 19:39, 25 November 2010 (UTC)

Well, "issues" there was meant to cover "bugs" and "suggestions", as the tracker does both. I'll make it more explicit though. [[User:Martin Dougiamas|Martin Dougiamas]] 10:12, 30 November 2010 (UTC)

OK - I could live with this. But I still prefer this clearer distinction as suggested by Mark:

===User role===

# Uses Moodle
# Finds issues/bugs (report in tracker)
# Suggests improvements (report in tracker)

Question: is there a way in the tracker to keep issues in two lists: bugs and suggestions? Maybe even like Google: you can suggest anything, but at any given time there are a few suggestions up for vote? In Moodle, you can discuss anything, but someone is highlighting at any given time a few topics for focused discussions. On reflection the answer may be No - on this basis I am back to my original suggestion.

A bug is a bug - it is not working as we know it should. A suggestion for an enhancement is partly an invitation to dialogue, vote. Voting for bugs is silly - all bugs need fixing, and priorities are best (IMO) determined centrally. So:

#Uses Moodle
#Finds and reports bugs (use tracker)
#Suggests improvements (use tracker)
#Takes part in dialogue around suggested improvements

[[User:Derek Chirnside|Derek Chirnside]] 06:18, 4 December 2010 (UTC)

:Derek, thanks for your comments. Regarding a way in the tracker to keep issues in two lists: bugs and suggestions, when you create an issue you have a choice of issue types - bug, new feature, task and improvement. Thus, a search for all new features and improvements should generate a list of suggestions. --[[User:Helen Foster|Helen Foster]] 14:31, 4 December 2010 (UTC)

== Backlog naming ==

Regarding the latest change about naming backlog versions with "STABLEBACKLOG/DEVBACKLOG", I'd recommend to use instead something like: "1.9.x backlog/2.0.x backlog/2.1.x backlog" because:

# It saves us to move things when a new major release happens (so it won't be necessary to move all the DEVBACKLOG => STABLEBACKLOG".
# It supports '''multiple''' stable branches, like we have now (1.9.x, 2.0.x...)
# It respects the format used by both the Affected Branches and Fixed Branches custom fields that are really useful for a lot of filters.

Ciao, [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 23:33, 6 December 2010 (UTC) :-)

:Addenda: Finally it has been decided to go to 2 backlogs only (stable/dev). Fair enough so developer (team) will look to the real branches were solution needs to be implemented. [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 10:23, 9 December 2010 (UTC)

==This does not look like scrum to me at all==

I think we need a certified scrum master. This proposal IMHO seems to break nearly all the good Scrum practises described in books.

Ciao, [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] 10:03, 9 December 2010 (UTC)

:Agree! some points (see point 3 especially, both in STABLE/DEV teams, break the thing. It's (scrum, by team) master responsibility to discuss with product owner, not team itself! Isolation is a MUST.

: Ciao, [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 10:12, 9 December 2010 (UTC)

----

== If the issue is a bug in the current stable version requiring database changes, assign "Fix version" to DEVBACKLOG ==

Hmm, maybe this should be governed up by bug severity too? You, sure, aren't going to say that every bug requiring DB update, however severe it is, should be left up to the next major release? --[[User:Oleg Sychev|Oleg Sychev]] 14:51, 9 December 2010 (UTC)

I understand the idea of pulling from the items with the highest priority; however, how are we going to determine that priority. We have issue severity which has traditionally been seen as a priority indicator but we also have the number of votes. I am curious when paper cuts will be taken care of. These smaller issues can impact the user experience. I suspect in an ideal world, all the major issues will be dealt with but occasionally some simple fixes come along with patches in the tracker and it would be good to get those applied. Peace - Anthony

: Well, in practice I expect people will choose items based on a cost/benefit analysis of fixing them - just like they always have in the past.--[[User:Tim Hunt|Tim Hunt]] 18:14, 16 December 2010 (UTC)

== Suggested changes for "External Developers" ==
I had a really good conversation with David (He posted a screenshot that maybe does a better job of explaining what is described below: http://picasaweb.google.com/david.mudrak/Moodle#5551427587739059122), and we discussed one possible suggested workflow external developers can use if they choose to use their own GIT repo. Here's how it would break down:

=== Creating repo ===
==== Branch off MOODLE_20_STABLE (ie: UCLA_TRUNK) ====
$ git --bare fetch git://git.moodle.org/moodle.git MOODLE_20_STABLE:MOODLE_20_STABLE
$ git checkout -b UCLA_TRUNK origin/MOODLE_20_STABLE

==== commit customizations into branch ====
$ ... (hack something, git add, git commit)
$ git push

=== Contributing back ===
==== Create another branch off MOODLE_20_STABLE (ie: COOL_NEW_FEATURE) ====
$ git --bare fetch git://git.moodle.org/moodle.git MOODLE_20_STABLE:MOODLE_20_STABLE
$ git checkout -b COOL_NEW_FEATURE origin/MOODLE_20_STABLE

==== git cherry-pick to selectively pick commits from UCLA_TRUNK to merge into COOL_NEW_FEATURE ====
git cherry-pick 7300a6130d9447e18a931e898b64eefedea19544

==== publish branch COOL_NEW_FEATURE ====
??

==== create pull request in tracker ====
http://tracker.moodle.org/secure/CreateIssue!default.jspa (Is this the right place?)

If accepted, it becomes part of core moodle

=== Updating to next version of Moodle ===
git pull

Talk:Process

2010-12-16T23:46:39Z

Moerderin:

I think 'User' should be described as both 'finding issues' and 'suggesting improvements' for Moodle, even if the detail of how things are implemented are left for the Product Owner. Just thinking that a good chunk of the things I add to the Tracker are suggestions for improvement rather than 'issues' as such and that we should promote this idea as a general rule - maybe :)

:I agree with Mark. Bug tracker should be used for actual bugs. Discussion about future roadmaps, enhcnements and improvements is a separate matter, and in actual fact it is hard to engage in this. I don't have an answer at the moment. Maybe a place to discuss, and notification of when discussions have heated up (like specs are being prepared and a new roadmap developed for a component) ie owners manage the discussion, but there is a clear place to go to engage, some indication of timelines etc. --[[User:Derek Chirnside|Derek Chirnside]] 19:39, 25 November 2010 (UTC)

Well, "issues" there was meant to cover "bugs" and "suggestions", as the tracker does both. I'll make it more explicit though. [[User:Martin Dougiamas|Martin Dougiamas]] 10:12, 30 November 2010 (UTC)

OK - I could live with this. But I still prefer this clearer distinction as suggested by Mark:

===User role===

# Uses Moodle
# Finds issues/bugs (report in tracker)
# Suggests improvements (report in tracker)

Question: is there a way in the tracker to keep issues in two lists: bugs and suggestions? Maybe even like Google: you can suggest anything, but at any given time there are a few suggestions up for vote? In Moodle, you can discuss anything, but someone is highlighting at any given time a few topics for focused discussions. On reflection the answer may be No - on this basis I am back to my original suggestion.

A bug is a bug - it is not working as we know it should. A suggestion for an enhancement is partly an invitation to dialogue, vote. Voting for bugs is silly - all bugs need fixing, and priorities are best (IMO) determined centrally. So:

#Uses Moodle
#Finds and reports bugs (use tracker)
#Suggests improvements (use tracker)
#Takes part in dialogue around suggested improvements

[[User:Derek Chirnside|Derek Chirnside]] 06:18, 4 December 2010 (UTC)

:Derek, thanks for your comments. Regarding a way in the tracker to keep issues in two lists: bugs and suggestions, when you create an issue you have a choice of issue types - bug, new feature, task and improvement. Thus, a search for all new features and improvements should generate a list of suggestions. --[[User:Helen Foster|Helen Foster]] 14:31, 4 December 2010 (UTC)

== Backlog naming ==

Regarding the latest change about naming backlog versions with "STABLEBACKLOG/DEVBACKLOG", I'd recommend to use instead something like: "1.9.x backlog/2.0.x backlog/2.1.x backlog" because:

# It saves us to move things when a new major release happens (so it won't be necessary to move all the DEVBACKLOG => STABLEBACKLOG".
# It supports '''multiple''' stable branches, like we have now (1.9.x, 2.0.x...)
# It respects the format used by both the Affected Branches and Fixed Branches custom fields that are really useful for a lot of filters.

Ciao, [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 23:33, 6 December 2010 (UTC) :-)

:Addenda: Finally it has been decided to go to 2 backlogs only (stable/dev). Fair enough so developer (team) will look to the real branches were solution needs to be implemented. [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 10:23, 9 December 2010 (UTC)

==This does not look like scrum to me at all==

I think we need a certified scrum master. This proposal IMHO seems to break nearly all the good Scrum practises described in books.

Ciao, [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] 10:03, 9 December 2010 (UTC)

:Agree! some points (see point 3 especially, both in STABLE/DEV teams, break the thing. It's (scrum, by team) master responsibility to discuss with product owner, not team itself! Isolation is a MUST.

: Ciao, [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 10:12, 9 December 2010 (UTC)

----

== If the issue is a bug in the current stable version requiring database changes, assign "Fix version" to DEVBACKLOG ==

Hmm, maybe this should be governed up by bug severity too? You, sure, aren't going to say that every bug requiring DB update, however severe it is, should be left up to the next major release? --[[User:Oleg Sychev|Oleg Sychev]] 14:51, 9 December 2010 (UTC)

I understand the idea of pulling from the items with the highest priority; however, how are we going to determine that priority. We have issue severity which has traditionally been seen as a priority indicator but we also have the number of votes. I am curious when paper cuts will be taken care of. These smaller issues can impact the user experience. I suspect in an ideal world, all the major issues will be dealt with but occasionally some simple fixes come along with patches in the tracker and it would be good to get those applied. Peace - Anthony

: Well, in practice I expect people will choose items based on a cost/benefit analysis of fixing them - just like they always have in the past.--[[User:Tim Hunt|Tim Hunt]] 18:14, 16 December 2010 (UTC)

== Suggested changes for "External Developers" ==
I had a really good conversation with David (He posted a screenshot that maybe does a better job of explaining what is described below: http://picasaweb.google.com/david.mudrak/Moodle#5551427587739059122), and we discussed one possible suggested workflow external developers can use if they choose to use their own GIT repo. Here's how it would break down:

=== Creating repo ===
==== Branch off MOODLE_20_STABLE (ie: UCLA_TRUNK) ====
$ git --bare fetch git://git.moodle.org/moodle.git MOODLE_20_STABLE:MOODLE_20_STABLE
$ git checkout -b UCLA_TRUNK origin/MOODLE_20_STABLE

==== commit customizations into branch ====
$ ... (hack something, git add, git commit)
$ git push

=== Contributing back ===
==== Create another branch off MOODLE_20_STABLE (ie: COOL_NEW_FEATURE) ====
$ git --bare fetch git://git.moodle.org/moodle.git MOODLE_20_STABLE:MOODLE_20_STABLE
$ git checkout -b COOL_NEW_FEATURE origin/MOODLE_20_STABLE

==== git cherry-pick to selectively pick commits from UCLA_TRUNK to merge into COOL_NEW_FEATURE ====
git cherry-pick 7300a6130d9447e18a931e898b64eefedea19544

==== publish branch COOL_NEW_FEATURE ====
??

==== create pull request in tracker ====
http://tracker.moodle.org/secure/CreateIssue!default.jspa (Is this the right place?)

If accepted, it becomes part of core moodle

=== Updating to next version of Moodle ===
git pull

Talk:Process

2010-12-16T21:10:08Z

Moerderin:

I think 'User' should be described as both 'finding issues' and 'suggesting improvements' for Moodle, even if the detail of how things are implemented are left for the Product Owner. Just thinking that a good chunk of the things I add to the Tracker are suggestions for improvement rather than 'issues' as such and that we should promote this idea as a general rule - maybe :)

:I agree with Mark. Bug tracker should be used for actual bugs. Discussion about future roadmaps, enhcnements and improvements is a separate matter, and in actual fact it is hard to engage in this. I don't have an answer at the moment. Maybe a place to discuss, and notification of when discussions have heated up (like specs are being prepared and a new roadmap developed for a component) ie owners manage the discussion, but there is a clear place to go to engage, some indication of timelines etc. --[[User:Derek Chirnside|Derek Chirnside]] 19:39, 25 November 2010 (UTC)

Well, "issues" there was meant to cover "bugs" and "suggestions", as the tracker does both. I'll make it more explicit though. [[User:Martin Dougiamas|Martin Dougiamas]] 10:12, 30 November 2010 (UTC)

OK - I could live with this. But I still prefer this clearer distinction as suggested by Mark:

===User role===

# Uses Moodle
# Finds issues/bugs (report in tracker)
# Suggests improvements (report in tracker)

Question: is there a way in the tracker to keep issues in two lists: bugs and suggestions? Maybe even like Google: you can suggest anything, but at any given time there are a few suggestions up for vote? In Moodle, you can discuss anything, but someone is highlighting at any given time a few topics for focused discussions. On reflection the answer may be No - on this basis I am back to my original suggestion.

A bug is a bug - it is not working as we know it should. A suggestion for an enhancement is partly an invitation to dialogue, vote. Voting for bugs is silly - all bugs need fixing, and priorities are best (IMO) determined centrally. So:

#Uses Moodle
#Finds and reports bugs (use tracker)
#Suggests improvements (use tracker)
#Takes part in dialogue around suggested improvements

[[User:Derek Chirnside|Derek Chirnside]] 06:18, 4 December 2010 (UTC)

:Derek, thanks for your comments. Regarding a way in the tracker to keep issues in two lists: bugs and suggestions, when you create an issue you have a choice of issue types - bug, new feature, task and improvement. Thus, a search for all new features and improvements should generate a list of suggestions. --[[User:Helen Foster|Helen Foster]] 14:31, 4 December 2010 (UTC)

== Backlog naming ==

Regarding the latest change about naming backlog versions with "STABLEBACKLOG/DEVBACKLOG", I'd recommend to use instead something like: "1.9.x backlog/2.0.x backlog/2.1.x backlog" because:

# It saves us to move things when a new major release happens (so it won't be necessary to move all the DEVBACKLOG => STABLEBACKLOG".
# It supports '''multiple''' stable branches, like we have now (1.9.x, 2.0.x...)
# It respects the format used by both the Affected Branches and Fixed Branches custom fields that are really useful for a lot of filters.

Ciao, [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 23:33, 6 December 2010 (UTC) :-)

:Addenda: Finally it has been decided to go to 2 backlogs only (stable/dev). Fair enough so developer (team) will look to the real branches were solution needs to be implemented. [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 10:23, 9 December 2010 (UTC)

==This does not look like scrum to me at all==

I think we need a certified scrum master. This proposal IMHO seems to break nearly all the good Scrum practises described in books.

Ciao, [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] 10:03, 9 December 2010 (UTC)

:Agree! some points (see point 3 especially, both in STABLE/DEV teams, break the thing. It's (scrum, by team) master responsibility to discuss with product owner, not team itself! Isolation is a MUST.

: Ciao, [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 10:12, 9 December 2010 (UTC)

----

== If the issue is a bug in the current stable version requiring database changes, assign "Fix version" to DEVBACKLOG ==

Hmm, maybe this should be governed up by bug severity too? You, sure, aren't going to say that every bug requiring DB update, however severe it is, should be left up to the next major release? --[[User:Oleg Sychev|Oleg Sychev]] 14:51, 9 December 2010 (UTC)

I understand the idea of pulling from the items with the highest priority; however, how are we going to determine that priority. We have issue severity which has traditionally been seen as a priority indicator but we also have the number of votes. I am curious when paper cuts will be taken care of. These smaller issues can impact the user experience. I suspect in an ideal world, all the major issues will be dealt with but occasionally some simple fixes come along with patches in the tracker and it would be good to get those applied. Peace - Anthony

: Well, in practice I expect people will choose items based on a cost/benefit analysis of fixing them - just like they always have in the past.--[[User:Tim Hunt|Tim Hunt]] 18:14, 16 December 2010 (UTC)

== Suggested changes for "External Developers" ==
I had a really good conversation with David, and we discussed one possible suggested workflow external developers can use if they choose to use their own GIT repo. Here's how it would break down:

#Creating repo
##Branch off MOODLE_20_STABLE (ie: UCLA_TRUNK)
##commit customizations into branch
#Contributing back
##Create another branch off MOODLE_20_STABLE (ie: COOL_NEW_FEATURE)
##git cherry-pick to selectively pick commits from UCLA_TRUNK to merge into COOL_NEW_FEATURE
##publish branch COOL_NEW_FEATURE
##create pull request in tracker
##if accepted, it becomes part of core moodle
#Updating to next version of Moodle
##git pull to UCLA_TRUNK, and since git recognizes that the patch is already in our repo, it does not try to reapply it.

Talk:Module visibility and display

2010-12-15T17:37:30Z

Moerderin: New page: UCLA is very excited about this feature. Currently we are using a patch that we call public/private (http://moodle.org/mod/data/view.php?d=13&rid=2768) to accomplish this functionality. ...

UCLA is very excited about this feature. Currently we are using a patch that we call public/private (http://moodle.org/mod/data/view.php?d=13&rid=2768) to accomplish this functionality.

This proposed feature would remove the need to maintain our customized code.

Additionally, allowing the developers to add custom editing icons next to resources/activities without modifying core moodle is an excellent idea!
--[[User:Nick Thompson|Nick Thompson]] 17:37, 15 December 2010 (UTC)

Talk:PublicPrivate

2010-09-24T15:45:33Z

Moerderin:

== Able to do this with roles?==
Can't you do this with roles? I think you should be able to.--[[User:Tim Hunt|Tim Hunt]] 00:18, 10 July 2009 (UTC)

== Don't think so but we're open to ideas ==

A couple years back our programmer, Mike Franks, had a conversation with both Martin Langhoff, and Martin Dougiamas. Basically we had a need to make activities and resources either available to everyone, or private and only available to members of that course. Both Martin's mentioned that it can be done with Groups and Groupings, so we went based off that suggestion. The problem is, it is too complicated to setup for the average instructor, so we automated the process.

Every time a course is created when this feature is turned on, a group "Course Members" is created, and the grouping "Private Course Material" is created. All the members of that course automatically get dropped into the Course Members group. With that automation in place, all a professor needs to worry about now is clicking the little lock icon to control access to any resource or activity.

If you would like to see this in action I can set you up with an account on our TEST server. --[[User:Nick Thompson|Nick Thompson]] 01:17, 11 October 2009 (UTC)

== How does PublicPrivate compare with OpenShare? ==

Both developments look like they could provide solutions for institutions who want to gradually open existing courses, in a cost-effective way that's also very easy for teaching staff to manage. An important step towards "OCW 2.0"? It would be a pity to have two independent paths that lead to the same end.

OpenShare: http://flexknowlogy.learningfield.org/addons/openshare/
--[[User:Alan Arnold|Alan Arnold]] 10:05, 7 October 2009 (UTC)

== How OpenShare Compares ==
OpenShare does this with Roles. I have not updated OpenShare since October 2008, despite my best intentions, but I'd love to regain that motivation if there are needs.

One concern with this Public/Private article: it refers to Resources, not Resources and Activities. Resources are much easier to simply share (because of the Guest role); Activities require a user account. (OpenShare does both). [[User:Jared Stein 2|Jared Stein 2]] 14:59, 7 October 2009 (UTC)

Actually, Public/Private does BOTH resources AND activities. --[[User:Nick Thompson|Nick Thompson]] 01:17, 11 October 2009 (UTC)

== Public/Private vs. Openshare ==

Here is an objective look at the KEY differences between Public/Private, and OpenShare. (If I leave anything out, feel free to add it. Do NOT add something if it is a PRO for both public/private, as that defeats the purpose of this.)

===Public/Private:===
====PRO's: ====
#No setup, once it's installed and turned on, any newly created course will have public/private enabled 
#Make resources public/private from the course main page 

====CON's:====
#Modifies Core Moodle 

===OpenShare:===
====PRO's:====
#Does NOT modify CORE Moodle 
#Deals with licensing

====CON's:====
#There is no way to mark resources as public/private from the course home page, you have to go to a management page to do this. 
#Have to manually update the student group assignments every time a new student is added to the course 
#Have to add the block, then have to "turn on" openshare before you can start using it. (for every course) 
--[[User:Nick Thompson|Nick Thompson]] 01:18, 11 October 2009 (UTC)

== Moodle 2 ==

Is there any plan to make a "moodle 2" version of this patch?
As far as I can see, Moodle2 does not feature public/private control. However, it is now possible to specify a "licence" on various files. Maybe it would be possible to specify what licences guests can actually see when they move through a course, but this does not seem possible.

We will begin upgrading this for moodle 2 as soon as it comes out. We anticipate the upgrade to take roughly a month or two.--[[User:Nick Thompson|Nick Thompson]] 15:45, 24 September 2010 (UTC)

Talk:Web services API - Function List

2009-10-29T18:53:48Z

Moerderin:

I moved the comments stuff to the actual page so that this can be used for it's intended purpose - comments.
--[[User:Nick Thompson|Nick Thompson]] 18:53, 29 October 2009 (UTC)----

Talk:Web services API - Function List

2009-10-29T18:53:34Z

Moerderin:

I moved the comments stuff to the actual page so that this can be used for it's intended purpose - comments.
----

Talk:Web services API - Function List

2009-10-29T18:53:23Z

Moerderin: Replacing page with 'I moved the comments stuff to the actual page so that this can be used for it's intended purpose - comments.'

I moved the comments stuff to the actual page so that this can be used for it's intended purpose - comments.

Web services API - Function List

2009-10-29T18:52:35Z

Moerderin: New page: Following some old suggestion. I'll integrate them in the page with the time. ==add_users== I think we should require all data needed for a successful "first login" to Moodle without popp...

Following some old suggestion. I'll integrate them in the page with the time.

==add_users==
I think we should require all data needed for a successful "first login" to Moodle without popping him out the profile page to fill in all missing required data. This may require extra inputs such as city, description ... (unsure of the full list depending of Moodle version ?).
Also password should be "required" if authentication method is "internal" .

INPUT:
one or more of these in an array
firstname
lastname
email
idnumber
login
authentication method (optional , default= manual ?)

OPERATION:
Adds one or more new users to the user database

OUTPUT:
array of ids or false

==delete_users==
INPUT:
String: field name ('id' or 'idnumber' or 'email' or 'login')
Array: values

OPERATION:
User is marked as deleted
All it's role assignments are destroyed
OUTPUT:
true/false

To Be Defined:
*Security: avoid devastating calls such as delete_users ('confirmed',array(1)) or delete_users('firstname',array('patrick')). Where to implement it?
*Wildcards: such as delete_users (array('idnumber','CS%'). Permit or not?

==get_users==
INPUT:
one or more of these
idnumber or
email or
id or
login

OPERATION:
user record with optional fields set (Moodle 1.8 and later) and maybe some fields filtered out (password,
email if user said not to disclose it ...) depending of the identity of the "caller" (admin or the user himself)

OUTPUT:
false or user record

==add_courses==
INPUT:
one or more of these in an array
name
shortname
format (default topics)
idnumber

OPERATION:
Adds a new course to the course table

OUTPUT:
id or false

==delete_courses==
INPUT:
one or more of these in an array
name OR
shortname OR
idnumber OR
id

OPERATION:
Deletes courses from the course table
What about associated ressources, roles ...

OUTPUT:
true or false

==get_courses==
INPUT:
one or more of these in an array
id or idnumber or shortname

OPERATION:
fetch course record with some fields filtered out depending of the "caller" identity (admin, teacher, student ...)
OUTPUT:
false or course records in an array

Doubts: so id , idenumber or shortname stands for... user, category, the very course you want to get itself?

==add_enrolments==
INPUT:
course unique Id (Moodle's ID or idnumber or shortname) (could be one or an array)
user unique id (Moodle's ID or idnumber or login or email) (could be one or an array)
role id (id or shortname or legacy capability name) (could be one or an array)

OPERATION:
assign given user a given role to given course

OUTPUT:
true or false

==delete_enrolments==
INPUT:
course unique Id (Moodle's ID or idnumber or shortname) (could be one or an array)
user unique id (Moodle's ID or idnumber or login or email) (could be one or an array)
role id (teacher, non editing teacher, student (?) ...) (could be one or an array)

OPERATION:
remove given user's "standard" role from given course

OUTPUT:
true or false

==get_enrolments==

INPUT:
user unique id (Moodle's ID or idnumber or login or email)
context course or site

OPERATION:
return a "list" of course's id in which given user move given user has some role assigned
return all the roles for a given courseid

OUTPUT:
"array" of (course id, course shortname, course fullname, role id, role name, course url)
or false in case of error (bad user id)

==get_recent_activity==

INPUT:
user unique id (Moodle's ID or idnumber or login or email)
course unique Id (Moodle's ID ,idnumber or shortname) - optional (default = all my courses)
timestamp - optional (default = time of last connexion in every course)

OPERATION:
return a "list" of changes (resource added/modified, new activities, etc.) for courses in which given user has some role assigned - since timestamp or last connexion in given course

OUTPUT:
"array" of (course id, course shortname, course fullname, role id, role name, url of the resource/activity, time of change)
or false in case of error (bad user/course id)

==get_grades==

(see grade_get_course_grade in grade/querylib.php)

INPUT:
user unique id (Moodle's ID or idnumber or login or email)
course unique Id (Moodle's ID ,idnumber or shortname) - optional (default = all my courses)

OPERATION:
return a "list" of grades and statistics for the given student in the given course

OUTPUT:
"array" of grades records (name,maxgrade,grade,percent,weight,weighted,sortOrder)
and "array" of stats (gradeItems,allgrades, points,totalpoints, percent, weight, weighted;)
or false in case of error (bad user/course id or user not in course)

==get_groups==

OPERATION:
return a "list" of group records in a given course (or site ?)

==add_groups==

==delete_groups==

==get_group_members==

OPERATION:
return a "list" of ids for members of a group (within a course or global)

==add_group_members==

OPERATION:
add new members to a group

==delete_group_members==

OPERATION:
remove membership from a group

==add_calendar_events==

OPERATION:
add/modify an event in Moodle database (site, course, private ...)

==delete_calendar_events ==

OPERATION:
delete given events

==get_calendar_events==

OPERATION:
return in an "exportable" format (iCal, vCal ...)an event recorded in Moodle database (site, course, private ...)

== admin ==
This API is used to change Moodle configuration variables.
<code php>
...

///config values
set_admin_config($configs) //$configs is array("config" => array("value","description","code"))
get_admin_config($code)
get_admin_configs()

///Plugins > Activities
get_activity_module_config(...)
set_activity_module_config(...)
get_activity_modules(...)

///Plugins > Block
...

///Plugins > Filter
...

///Plugins > Portfolio
...

///Plugins > Repository
get_repository_plugins(...)
add_repository_plugins(...)
remove_repository_plugins(...)
get_repository_plugin_config(...)
set_repository_plugin_config(...)
get_repository_instances(...)
add_repository_instances(...)
remove_repository_instances(...)
get_repository_instance_config(...)
set_repository_instance_config(...)

///Security
get_security_config($pagename='') //return array("pagename" => array("config"=>"value"))
//usefull if you want retrieve all config in once for only for security

///Server
get_environment($version=null)
get_server_config($pagename='') //return array("pagename" => array("config"=>"value"))

...
</code>

== blocks ==
== blog ==
<code php>
get_blog_entries($userid, $startdate, $enddate, $number)
create_blog_entries($userid, $entries) //array of entry array
delete_blog_entries($entryids)
update_blog_entry($entry)
get_blog_user_preferences($userid) //return array of config (array("configname","value"))
set_blog_user_preferences($userid, $configs)
</code>

== calendar ==
<code php>
create_calendar_events(...)
delete_calendar_events(...)
get_calendar_events(...) //return in an "exportable" format (iCal, vCal ...)an event recorded in Moodle database (site, course, private ...)
</code>

== Category ==
get_category()
create_category()
delete_category()
update_category()
update_parent_category()

== course ==
<code php>
create_courses($arrayCourses)
create_course_enrolments($role,$criteria_course,$course,$criteria_user,$users)
delete_courses($criteria, $arrayCourses)
delete_course_enrolments($role,$criteria_course,$course,$criteria_user,$users)
get_courses($criteria, $arraySearch)
get_course_enrolments($criteria_user,$user)
get_courses_recent_activities($criteria, $arrayCourses)

get_course_activities($courseid=0, $groupid=null) // return the list of activity {id, name, type}
get_course_resources($courseid=0, $groupid=null) // return the list of {id,. resource, type}
create_section()
get_sections()
delete_section()
get_metacourse()
</code>

=== Course Format ===
get_course_outline($courseid=0, $groupid=null) // to discuss, maybe xml stuff

get_course_outline would be a nice to have from the webservices consumer app. If an external app needs to render the moodle course, need's more than just activities and resources, it needs to know how to display it. this function whould be implemented by the course format.

TODO: define course outline xml dtd

== grade ==
<code php>
get_grades(...)
</code>

== group ==
<code php>
add_group_members($criteriaCourse, $course, $criteriaUser, $arrayUsers, $groupname)
create_groups($criteria, $course, $groupnames)
delete_groups($criteria, $course, $groupnames)
get_groups($criteria, $course)
get_groups_by_course($courseid)
get_group_members($criteria, $course, $groupname)
remove_group_members($criteriaCourse, $course, $criteriaUser, $arrayUsers, $groupname)
set_group(...)
update_group(...)

create_grouping()
delete_grouping()
update_grouping()
get_grouping()
add_group_to_grouping()
get_groups_from_grouping()
delete_group_from_grouping()
</code>

== mod ==
=== assignment ===
=== chat ===
=== choice ===
=== data ===
=== feedback ===
=== forum ===
<code php>
get_forums_by_courses($courseids)
get_forums_discussions($discussions=null, $forumids=null, $courseids) //you can retrieve discussions by id
//and/or by forums and/or by courses
get_forums_posts_by_discussions($discussionids)
get_forums_posts($postids)
set_forum_posts($posts)
update_forum_posts($posts)
create_forum_posts($discussionid, $posts)
create_forum_discussiosn($courseid, $discussions)
set_forum_discussions($discussions)
update_forum_discussions($discussions)
delete_forum_discussions($discussions)
delete_forum_posts($posts)
search_forum_string($stringtosearch, $forumids=null, $discussionids=null)
</code>

=== glossary ===
=== lesson ===
=== quiz ===

=== resource ===
=== scorm ===
=== survey ===
=== wiki ===
== portfolio ==
== repository ==
<code php>
///functions to let teacher and user manage their repositories
get_repository_instances($repository_type=null, $userid=null, $courseid=null) //if courseid!=null, get course level instances,
//else if userid != null get user level instances
add_repository_instances($repositoryinstances)
remove_repository_instances($repositoryinstances)
get_repository_instance_config($repositoryinstanceid)
set_repository_instance_config($repositoryinstanceid,$configs)
</code>
== Role ==
create_role()
get_roles()
update_role()
delete_role()
assign_role()
inherit_capability()
allow_capability()
prevent_capability()
prohibit_capability()
get_users_by_role()
has_capability()

== search ==
<code php>
search($string);
</code>

==tag==

== user ==
<code php>
create_users($users) //$users is an array of $user
//$user is an array(username, password, forcechangepwd, firstname,
// lastname, email, emaildisplay, emailactivated,
// city, country, timezone, language, description,...)
delete_users($criteria, $users)
get_users($criteria, $users)
set_user($user) //$user is an array(...)
update_user($user) //$user is an array(...)
</code>

Talk:PublicPrivate

2009-10-14T18:00:42Z

Moerderin: /* PRO's: */

Talk:PublicPrivate

2009-10-11T01:18:07Z

Moerderin: /* Public/Private vs. Openshare */

== Able to do this with roles?==
Can't you do this with roles? I think you should be able to.--[[User:Tim Hunt|Tim Hunt]] 00:18, 10 July 2009 (UTC)

== Don't think so but we're open to ideas ==

A couple years back our programmer, Mike Franks, had a conversation with both Martin Langhoff, and Martin Dougiamas. Basically we had a need to make activities and resources either available to everyone, or private and only available to members of that course. Both Martin's mentioned that it can be done with Groups and Groupings, so we went based off that suggestion. The problem is, it is too complicated to setup for the average instructor, so we automated the process.

Every time a course is created when this feature is turned on, a group "Course Members" is created, and the grouping "Private Course Material" is created. All the members of that course automatically get dropped into the Course Members group. With that automation in place, all a professor needs to worry about now is clicking the little lock icon to control access to any resource or activity.

If you would like to see this in action I can set you up with an account on our TEST server. --[[User:Nick Thompson|Nick Thompson]] 01:17, 11 October 2009 (UTC)

== How does PublicPrivate compare with OpenShare? ==

Both developments look like they could provide solutions for institutions who want to gradually open existing courses, in a cost-effective way that's also very easy for teaching staff to manage. An important step towards "OCW 2.0"? It would be a pity to have two independent paths that lead to the same end.

OpenShare: http://flexknowlogy.learningfield.org/addons/openshare/
--[[User:Alan Arnold|Alan Arnold]] 10:05, 7 October 2009 (UTC)

== How OpenShare Compares ==
OpenShare does this with Roles. I have not updated OpenShare since October 2008, despite my best intentions, but I'd love to regain that motivation if there are needs.

One concern with this Public/Private article: it refers to Resources, not Resources and Activities. Resources are much easier to simply share (because of the Guest role); Activities require a user account. (OpenShare does both). [[User:Jared Stein 2|Jared Stein 2]] 14:59, 7 October 2009 (UTC)

Actually, Public/Private does BOTH resources AND activities. --[[User:Nick Thompson|Nick Thompson]] 01:17, 11 October 2009 (UTC)

== Public/Private vs. Openshare ==

Here is an objective look at the KEY differences between Public/Private, and OpenShare. (If I leave anything out, feel free to add it. Do NOT add something if it is a PRO for both public/private, as that defeats the purpose of this.)

===Public/Private:===
====PRO's: ====
#No setup, once it's installed and turned on, any newly created course will have public/private enabled 
#Make resources public/private from the course main page 

====CON's:====
#Modifies Core Moodle 

===OpenShare:===
====PRO's:====
#Does NOT modify CORE Moodle 

====CON's:====
#There is no way to mark resources as public/private from the course home page, you have to go to a management page to do this. 
#Have to manually update the student group assignments every time a new student is added to the course 
#Have to add the block, then have to "turn on" openshare before you can start using it. (for every course) 
--[[User:Nick Thompson|Nick Thompson]] 01:18, 11 October 2009 (UTC)

Talk:PublicPrivate

2009-10-11T01:17:45Z

Moerderin: /* How OpenShare Compares */

== Able to do this with roles?==
Can't you do this with roles? I think you should be able to.--[[User:Tim Hunt|Tim Hunt]] 00:18, 10 July 2009 (UTC)

== Don't think so but we're open to ideas ==

A couple years back our programmer, Mike Franks, had a conversation with both Martin Langhoff, and Martin Dougiamas. Basically we had a need to make activities and resources either available to everyone, or private and only available to members of that course. Both Martin's mentioned that it can be done with Groups and Groupings, so we went based off that suggestion. The problem is, it is too complicated to setup for the average instructor, so we automated the process.

Every time a course is created when this feature is turned on, a group "Course Members" is created, and the grouping "Private Course Material" is created. All the members of that course automatically get dropped into the Course Members group. With that automation in place, all a professor needs to worry about now is clicking the little lock icon to control access to any resource or activity.

If you would like to see this in action I can set you up with an account on our TEST server. --[[User:Nick Thompson|Nick Thompson]] 01:17, 11 October 2009 (UTC)

== How does PublicPrivate compare with OpenShare? ==

Both developments look like they could provide solutions for institutions who want to gradually open existing courses, in a cost-effective way that's also very easy for teaching staff to manage. An important step towards "OCW 2.0"? It would be a pity to have two independent paths that lead to the same end.

OpenShare: http://flexknowlogy.learningfield.org/addons/openshare/
--[[User:Alan Arnold|Alan Arnold]] 10:05, 7 October 2009 (UTC)

== How OpenShare Compares ==
OpenShare does this with Roles. I have not updated OpenShare since October 2008, despite my best intentions, but I'd love to regain that motivation if there are needs.

One concern with this Public/Private article: it refers to Resources, not Resources and Activities. Resources are much easier to simply share (because of the Guest role); Activities require a user account. (OpenShare does both). [[User:Jared Stein 2|Jared Stein 2]] 14:59, 7 October 2009 (UTC)

Actually, Public/Private does BOTH resources AND activities. --[[User:Nick Thompson|Nick Thompson]] 01:17, 11 October 2009 (UTC)

== Public/Private vs. Openshare ==

Here is an objective look at the KEY differences between Public/Private, and OpenShare. (If I leave anything out, feel free to add it. Do NOT add something if it is a PRO for both public/private, as that defeats the purpose of this.)

===Public/Private:===
====PRO's: ====
#No setup, once it's installed and turned on, any newly created course will have public/private enabled 
#Make resources public/private from the course main page 

====CON's:====
#Modifies Core Moodle 

===OpenShare:===
====PRO's:====
#Does NOT modify CORE Moodle 

====CON's:====
#There is no way to mark resources as public/private from the course home page, you have to go to a management page to do this. 
#Have to manually update the student group assignments every time a new student is added to the course 
#Have to add the block, then have to "turn on" openshare before you can start using it. (for every course)

Talk:PublicPrivate

2009-10-11T01:17:26Z

Moerderin: /* Don't think so but we're open to ideas */

== Able to do this with roles?==
Can't you do this with roles? I think you should be able to.--[[User:Tim Hunt|Tim Hunt]] 00:18, 10 July 2009 (UTC)

== Don't think so but we're open to ideas ==

A couple years back our programmer, Mike Franks, had a conversation with both Martin Langhoff, and Martin Dougiamas. Basically we had a need to make activities and resources either available to everyone, or private and only available to members of that course. Both Martin's mentioned that it can be done with Groups and Groupings, so we went based off that suggestion. The problem is, it is too complicated to setup for the average instructor, so we automated the process.

Every time a course is created when this feature is turned on, a group "Course Members" is created, and the grouping "Private Course Material" is created. All the members of that course automatically get dropped into the Course Members group. With that automation in place, all a professor needs to worry about now is clicking the little lock icon to control access to any resource or activity.

If you would like to see this in action I can set you up with an account on our TEST server. --[[User:Nick Thompson|Nick Thompson]] 01:17, 11 October 2009 (UTC)

== How does PublicPrivate compare with OpenShare? ==

Both developments look like they could provide solutions for institutions who want to gradually open existing courses, in a cost-effective way that's also very easy for teaching staff to manage. An important step towards "OCW 2.0"? It would be a pity to have two independent paths that lead to the same end.

OpenShare: http://flexknowlogy.learningfield.org/addons/openshare/
--[[User:Alan Arnold|Alan Arnold]] 10:05, 7 October 2009 (UTC)

== How OpenShare Compares ==
OpenShare does this with Roles. I have not updated OpenShare since October 2008, despite my best intentions, but I'd love to regain that motivation if there are needs.

One concern with this Public/Private article: it refers to Resources, not Resources and Activities. Resources are much easier to simply share (because of the Guest role); Activities require a user account. (OpenShare does both). [[User:Jared Stein 2|Jared Stein 2]] 14:59, 7 October 2009 (UTC)

Actually, Public/Private does BOTH resources AND activities.

== Public/Private vs. Openshare ==

Here is an objective look at the KEY differences between Public/Private, and OpenShare. (If I leave anything out, feel free to add it. Do NOT add something if it is a PRO for both public/private, as that defeats the purpose of this.)

===Public/Private:===
====PRO's: ====
#No setup, once it's installed and turned on, any newly created course will have public/private enabled 
#Make resources public/private from the course main page 

====CON's:====
#Modifies Core Moodle 

===OpenShare:===
====PRO's:====
#Does NOT modify CORE Moodle 

====CON's:====
#There is no way to mark resources as public/private from the course home page, you have to go to a management page to do this. 
#Have to manually update the student group assignments every time a new student is added to the course 
#Have to add the block, then have to "turn on" openshare before you can start using it. (for every course)

Talk:PublicPrivate

2009-10-10T19:47:42Z

Moerderin:

== Able to do this with roles?==
Can't you do this with roles? I think you should be able to.--[[User:Tim Hunt|Tim Hunt]] 00:18, 10 July 2009 (UTC)

== Don't think so but we're open to ideas ==

A couple years back our programmer, Mike Franks, had a conversation with both Martin Langhoff, and Martin Dougiamas. Basically we had a need to make activities and resources either available to everyone, or private and only available to members of that course. Both Martin's mentioned that it can be done with Groups and Groupings, so we went based off that suggestion. The problem is, it is too complicated to setup for the average instructor, so we automated the process.

Every time a course is created when this feature is turned on, a group "Course Members" is created, and the grouping "Private Course Material" is created. All the members of that course automatically get dropped into the Course Members group. With that automation in place, all a professor needs to worry about now is clicking the little lock icon to control access to any resource or activity.

If you would like to see this in action I can set you up with an account on our TEST server.

== How does PublicPrivate compare with OpenShare? ==

Both developments look like they could provide solutions for institutions who want to gradually open existing courses, in a cost-effective way that's also very easy for teaching staff to manage. An important step towards "OCW 2.0"? It would be a pity to have two independent paths that lead to the same end.

OpenShare: http://flexknowlogy.learningfield.org/addons/openshare/
--[[User:Alan Arnold|Alan Arnold]] 10:05, 7 October 2009 (UTC)

== How OpenShare Compares ==
OpenShare does this with Roles. I have not updated OpenShare since October 2008, despite my best intentions, but I'd love to regain that motivation if there are needs.

One concern with this Public/Private article: it refers to Resources, not Resources and Activities. Resources are much easier to simply share (because of the Guest role); Activities require a user account. (OpenShare does both). [[User:Jared Stein 2|Jared Stein 2]] 14:59, 7 October 2009 (UTC)

Actually, Public/Private does BOTH resources AND activities.

== Public/Private vs. Openshare ==

Here is an objective look at the KEY differences between Public/Private, and OpenShare. (If I leave anything out, feel free to add it. Do NOT add something if it is a PRO for both public/private, as that defeats the purpose of this.)

===Public/Private:===
====PRO's: ====
#No setup, once it's installed and turned on, any newly created course will have public/private enabled 
#Make resources public/private from the course main page 

====CON's:====
#Modifies Core Moodle 

===OpenShare:===
====PRO's:====
#Does NOT modify CORE Moodle 

====CON's:====
#There is no way to mark resources as public/private from the course home page, you have to go to a management page to do this. 
#Have to manually update the student group assignments every time a new student is added to the course 
#Have to add the block, then have to "turn on" openshare before you can start using it. (for every course)

Talk:PublicPrivate

2009-10-10T01:46:26Z

Moerderin: /* Public/Private vs. Openshare */

Can't you do this with roles? I think you should be able to.--[[User:Tim Hunt|Tim Hunt]] 00:18, 10 July 2009 (UTC)

== Don't think so but we're open to ideas ==

A couple years back our programmer, Mike Franks, had a conversation with both Martin Langhoff, and Martin Dougiamas. Basically we had a need to make activities and resources either available to everyone, or private and only available to members of that course. Both Martin's mentioned that it can be done with Groups and Groupings, so we went based off that suggestion. The problem is, it is too complicated to setup for the average instructor, so we automated the process.

Every time a course is created when this feature is turned on, a group "Course Members" is created, and the grouping "Private Course Material" is created. All the members of that course automatically get dropped into the Course Members group. With that automation in place, all a professor needs to worry about now is clicking the little lock icon to control access to any resource or activity.

If you would like to see this in action I can set you up with an account on our TEST server.

== How does PublicPrivate compare with OpenShare? ==

Both developments look like they could provide solutions for institutions who want to gradually open existing courses, in a cost-effective way that's also very easy for teaching staff to manage. An important step towards "OCW 2.0"? It would be a pity to have two independent paths that lead to the same end.

OpenShare: http://flexknowlogy.learningfield.org/addons/openshare/
--[[User:Alan Arnold|Alan Arnold]] 10:05, 7 October 2009 (UTC)

== How OpenShare Compares ==
OpenShare does this with Roles. I have not updated OpenShare since October 2008, despite my best intentions, but I'd love to regain that motivation if there are needs.

One concern with this Public/Private article: it refers to Resources, not Resources and Activities. Resources are much easier to simply share (because of the Guest role); Activities require a user account. (OpenShare does both). [[User:Jared Stein 2|Jared Stein 2]] 14:59, 7 October 2009 (UTC)

Actually, Public/Private does BOTH resources AND activities.

== Public/Private vs. Openshare ==

Here is an objective look at the KEY differences between Public/Private, and OpenShare. (If I leave anything out, feel free to add it. Do NOT add something if it is a PRO for both public/private, as that defeats the purpose of this.)

===Public/Private:===
====PRO's: ====
#No setup, once it's installed and turned on, any newly created course will have public/private enabled 
#Make resources public/private from the course main page 

====CON's:====
#Modifies Core Moodle 

===OpenShare:===
====PRO's:====
#Does NOT modify CORE Moodle 

====CON's:====
#There is no way to mark resources as public/private from the course home page, you have to go to a management page to do this. 
#Have to manually update the student group assignments every time a new student is added to the course 
#Have to add the block, then have to "turn on" openshare before you can start using it. (for every course)

Talk:PublicPrivate

2009-10-10T01:44:29Z

Moerderin: /* Public/Private vs. Openshare */

Can't you do this with roles? I think you should be able to.--[[User:Tim Hunt|Tim Hunt]] 00:18, 10 July 2009 (UTC)

== Don't think so but we're open to ideas ==

A couple years back our programmer, Mike Franks, had a conversation with both Martin Langhoff, and Martin Dougiamas. Basically we had a need to make activities and resources either available to everyone, or private and only available to members of that course. Both Martin's mentioned that it can be done with Groups and Groupings, so we went based off that suggestion. The problem is, it is too complicated to setup for the average instructor, so we automated the process.

Every time a course is created when this feature is turned on, a group "Course Members" is created, and the grouping "Private Course Material" is created. All the members of that course automatically get dropped into the Course Members group. With that automation in place, all a professor needs to worry about now is clicking the little lock icon to control access to any resource or activity.

If you would like to see this in action I can set you up with an account on our TEST server.

== How does PublicPrivate compare with OpenShare? ==

Both developments look like they could provide solutions for institutions who want to gradually open existing courses, in a cost-effective way that's also very easy for teaching staff to manage. An important step towards "OCW 2.0"? It would be a pity to have two independent paths that lead to the same end.

OpenShare: http://flexknowlogy.learningfield.org/addons/openshare/
--[[User:Alan Arnold|Alan Arnold]] 10:05, 7 October 2009 (UTC)

== How OpenShare Compares ==
OpenShare does this with Roles. I have not updated OpenShare since October 2008, despite my best intentions, but I'd love to regain that motivation if there are needs.

One concern with this Public/Private article: it refers to Resources, not Resources and Activities. Resources are much easier to simply share (because of the Guest role); Activities require a user account. (OpenShare does both). [[User:Jared Stein 2|Jared Stein 2]] 14:59, 7 October 2009 (UTC)

Actually, Public/Private does BOTH resources AND activities.

== Public/Private vs. Openshare ==

Here is an objective look at the KEY differences between Public/Private, and OpenShare. (If I leave anything out, feel free to add it. Do NOT add something if it is a PRO for both public/private, as that defeats the purpose of this.)

===Public/Private:===
====PRO's: ====
-No setup, once it's installed and turned on, any newly created course will have public/private enabled 
-Make resources public/private from the course main page 

====CON's:====
-Modifies Core Moodle 

===OpenShare:===
====PRO's:====
-Does NOT modify CORE Moodle 
-Others? 

====CON's:====
-There is no way to mark resources as public/private from the course home page, you have to go to a management page to do this. 
-Have to manually update the student group assignments every time a new student is added to the course 
-Have to add the block, then have to "turn on" openshare before you can start using it. (for every course)

Talk:PublicPrivate

2009-10-10T01:44:07Z

Moerderin: /* Public/Private vs. Openshare */

Can't you do this with roles? I think you should be able to.--[[User:Tim Hunt|Tim Hunt]] 00:18, 10 July 2009 (UTC)

== Don't think so but we're open to ideas ==

A couple years back our programmer, Mike Franks, had a conversation with both Martin Langhoff, and Martin Dougiamas. Basically we had a need to make activities and resources either available to everyone, or private and only available to members of that course. Both Martin's mentioned that it can be done with Groups and Groupings, so we went based off that suggestion. The problem is, it is too complicated to setup for the average instructor, so we automated the process.

Every time a course is created when this feature is turned on, a group "Course Members" is created, and the grouping "Private Course Material" is created. All the members of that course automatically get dropped into the Course Members group. With that automation in place, all a professor needs to worry about now is clicking the little lock icon to control access to any resource or activity.

If you would like to see this in action I can set you up with an account on our TEST server.

== How does PublicPrivate compare with OpenShare? ==

Both developments look like they could provide solutions for institutions who want to gradually open existing courses, in a cost-effective way that's also very easy for teaching staff to manage. An important step towards "OCW 2.0"? It would be a pity to have two independent paths that lead to the same end.

OpenShare: http://flexknowlogy.learningfield.org/addons/openshare/
--[[User:Alan Arnold|Alan Arnold]] 10:05, 7 October 2009 (UTC)

== How OpenShare Compares ==
OpenShare does this with Roles. I have not updated OpenShare since October 2008, despite my best intentions, but I'd love to regain that motivation if there are needs.

One concern with this Public/Private article: it refers to Resources, not Resources and Activities. Resources are much easier to simply share (because of the Guest role); Activities require a user account. (OpenShare does both). [[User:Jared Stein 2|Jared Stein 2]] 14:59, 7 October 2009 (UTC)

Actually, Public/Private does BOTH resources AND activities.

== Public/Private vs. Openshare ==

Here is an objective look at the KEY differences between Public/Private, and OpenShare. (If I leave anything out, feel free to add it. Do NOT add something if it is a PRO for both public/private, as that defeats the purpose of this.)

===Public/Private:===
====PRO's: ====
-No setup, once it's installed and turned on, any newly created course will have public/private enabled 
-Make resources public/private from the course main page 

====CON's:====
-Modifies Core Moodle 

===OpenShare:===
PRO's: 
-Does NOT modify CORE Moodle 
-Others? 

====CON's:====
-There is no way to mark resources as public/private from the course home page, you have to go to a management page to do this. 
-Have to manually update the student group assignments every time a new student is added to the course 
-Have to add the block, then have to "turn on" openshare before you can start using it. (for every course)

Talk:PublicPrivate

2009-10-10T01:43:20Z

Moerderin: /* Public/Private vs. Openshare */

Can't you do this with roles? I think you should be able to.--[[User:Tim Hunt|Tim Hunt]] 00:18, 10 July 2009 (UTC)

== Don't think so but we're open to ideas ==

A couple years back our programmer, Mike Franks, had a conversation with both Martin Langhoff, and Martin Dougiamas. Basically we had a need to make activities and resources either available to everyone, or private and only available to members of that course. Both Martin's mentioned that it can be done with Groups and Groupings, so we went based off that suggestion. The problem is, it is too complicated to setup for the average instructor, so we automated the process.

Every time a course is created when this feature is turned on, a group "Course Members" is created, and the grouping "Private Course Material" is created. All the members of that course automatically get dropped into the Course Members group. With that automation in place, all a professor needs to worry about now is clicking the little lock icon to control access to any resource or activity.

If you would like to see this in action I can set you up with an account on our TEST server.

== How does PublicPrivate compare with OpenShare? ==

Both developments look like they could provide solutions for institutions who want to gradually open existing courses, in a cost-effective way that's also very easy for teaching staff to manage. An important step towards "OCW 2.0"? It would be a pity to have two independent paths that lead to the same end.

OpenShare: http://flexknowlogy.learningfield.org/addons/openshare/
--[[User:Alan Arnold|Alan Arnold]] 10:05, 7 October 2009 (UTC)

== How OpenShare Compares ==
OpenShare does this with Roles. I have not updated OpenShare since October 2008, despite my best intentions, but I'd love to regain that motivation if there are needs.

One concern with this Public/Private article: it refers to Resources, not Resources and Activities. Resources are much easier to simply share (because of the Guest role); Activities require a user account. (OpenShare does both). [[User:Jared Stein 2|Jared Stein 2]] 14:59, 7 October 2009 (UTC)

Actually, Public/Private does BOTH resources AND activities.

== Public/Private vs. Openshare ==

Here is an objective look at the KEY differences between Public/Private, and OpenShare. (If I leave anything out, feel free to add it. Do NOT add something if it is a PRO for both public/private, as that defeats the purpose of this.)

Public/Private: 
PRO's: 
-No setup, once it's installed and turned on, any newly created course will have public/private enabled 
-Make resources public/private from the course main page 

CON's: 
-Modifies Core Moodle 

OpenShare: 
PRO's: 
-Does NOT modify CORE Moodle 
-Others? 

CON's: 
-There is no way to mark resources as public/private from the course home page, you have to go to a management page to do this. 
-Have to manually update the student group assignments every time a new student is added to the course 
-Have to add the block, then have to "turn on" openshare before you can start using it. (for every course)

Talk:PublicPrivate

2009-10-10T01:42:41Z

Moerderin: /* Public/Private vs. Openshare */

Can't you do this with roles? I think you should be able to.--[[User:Tim Hunt|Tim Hunt]] 00:18, 10 July 2009 (UTC)

== Don't think so but we're open to ideas ==

A couple years back our programmer, Mike Franks, had a conversation with both Martin Langhoff, and Martin Dougiamas. Basically we had a need to make activities and resources either available to everyone, or private and only available to members of that course. Both Martin's mentioned that it can be done with Groups and Groupings, so we went based off that suggestion. The problem is, it is too complicated to setup for the average instructor, so we automated the process.

Every time a course is created when this feature is turned on, a group "Course Members" is created, and the grouping "Private Course Material" is created. All the members of that course automatically get dropped into the Course Members group. With that automation in place, all a professor needs to worry about now is clicking the little lock icon to control access to any resource or activity.

If you would like to see this in action I can set you up with an account on our TEST server.

== How does PublicPrivate compare with OpenShare? ==

Both developments look like they could provide solutions for institutions who want to gradually open existing courses, in a cost-effective way that's also very easy for teaching staff to manage. An important step towards "OCW 2.0"? It would be a pity to have two independent paths that lead to the same end.

OpenShare: http://flexknowlogy.learningfield.org/addons/openshare/
--[[User:Alan Arnold|Alan Arnold]] 10:05, 7 October 2009 (UTC)

== How OpenShare Compares ==
OpenShare does this with Roles. I have not updated OpenShare since October 2008, despite my best intentions, but I'd love to regain that motivation if there are needs.

One concern with this Public/Private article: it refers to Resources, not Resources and Activities. Resources are much easier to simply share (because of the Guest role); Activities require a user account. (OpenShare does both). [[User:Jared Stein 2|Jared Stein 2]] 14:59, 7 October 2009 (UTC)

Actually, Public/Private does BOTH resources AND activities.

== Public/Private vs. Openshare ==

Here is an objective look at the KEY differences between Public/Private, and OpenShare. (If I leave anything out, feel free to add it. Do NOT add something if it is a PRO for both public/private, as that defeats the purpose of this.)

Public/Private:
PRO's: 
-No setup, once it's installed and turned on, any newly created course will have public/private enabled
-Make resources public/private from the course main page

CON's:
-Modifies Core Moodle

OpenShare:
PRO's:
-Does NOT modify CORE Moodle
-Others?

CON's:
-There is no way to mark resources as public/private from the course home page, you have to go to a management page to do this.
-Have to manually update the student group assignments every time a new student is added to the course
-Have to add the block, then have to "turn on" openshare before you can start using it. (for every course)

Talk:PublicPrivate

2009-10-10T01:42:16Z

Moerderin: /* Public/Private vs. Openshare */ new section

Can't you do this with roles? I think you should be able to.--[[User:Tim Hunt|Tim Hunt]] 00:18, 10 July 2009 (UTC)

== Don't think so but we're open to ideas ==

A couple years back our programmer, Mike Franks, had a conversation with both Martin Langhoff, and Martin Dougiamas. Basically we had a need to make activities and resources either available to everyone, or private and only available to members of that course. Both Martin's mentioned that it can be done with Groups and Groupings, so we went based off that suggestion. The problem is, it is too complicated to setup for the average instructor, so we automated the process.

Every time a course is created when this feature is turned on, a group "Course Members" is created, and the grouping "Private Course Material" is created. All the members of that course automatically get dropped into the Course Members group. With that automation in place, all a professor needs to worry about now is clicking the little lock icon to control access to any resource or activity.

If you would like to see this in action I can set you up with an account on our TEST server.

== How does PublicPrivate compare with OpenShare? ==

Both developments look like they could provide solutions for institutions who want to gradually open existing courses, in a cost-effective way that's also very easy for teaching staff to manage. An important step towards "OCW 2.0"? It would be a pity to have two independent paths that lead to the same end.

OpenShare: http://flexknowlogy.learningfield.org/addons/openshare/
--[[User:Alan Arnold|Alan Arnold]] 10:05, 7 October 2009 (UTC)

== How OpenShare Compares ==
OpenShare does this with Roles. I have not updated OpenShare since October 2008, despite my best intentions, but I'd love to regain that motivation if there are needs.

One concern with this Public/Private article: it refers to Resources, not Resources and Activities. Resources are much easier to simply share (because of the Guest role); Activities require a user account. (OpenShare does both). [[User:Jared Stein 2|Jared Stein 2]] 14:59, 7 October 2009 (UTC)

Actually, Public/Private does BOTH resources AND activities.

== Public/Private vs. Openshare ==

Here is an objective look at the KEY differences between Public/Private, and OpenShare. (If I leave anything out, feel free to add it. Do NOT add something if it is a PRO for both public/private, as that defeats the purpose of this.)

Public/Private:
PRO's:
-No setup, once it's installed and turned on, any newly created course will have public/private enabled
-Make resources public/private from the course main page

CON's:
-Modifies Core Moodle

OpenShare:
PRO's:
-Does NOT modify CORE Moodle
-Others?

CON's:
-There is no way to mark resources as public/private from the course home page, you have to go to a management page to do this.
-Have to manually update the student group assignments every time a new student is added to the course
-Have to add the block, then have to "turn on" openshare before you can start using it. (for every course)

PublicPrivate

2009-10-09T15:54:12Z

Moerderin:

== Executive Summary ==

This page will spec out the features of Public/Private.

Public/Private is a means whereby any resource/activity within moodle can be made private to only members of that course, or public and available to anyone that visits that site (including guests).

A practical use for this feature is making the syllabus public so that potential students can shop around for classes, but the rest of the course material is private and only available to the members of that course.

== Database structures ==
Below are the fields that are added to the already existing table.

=== course ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''groupautoassign'''
|BIGINT(10)
|0
|Group id to auto-assign members of the course.

|-
|'''grouppublicprivate'''
|TINYINT(1)
|0
|Whether public/private is enabled for that course.
|}

=== groups_members ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''type'''
|VARCHAR(36)
|NULL
|This field indicates whether the user was auto-assigned to a group, or not. (as opposed to manually added)
|}

== Overview of module communication ==

=== Setup ===
Setup is very simple. Once moodle is installed, All that needs to take place before using Public/Private is going into Administration->Miscellaneous->Experimental, and check both "Enable groupings", and "Enable Public/Private"

Now, create a course like normal, and add either a resource or activity to that course. The default behavior should be that when a resource or activity is added, it will read "(Private Course Material)" next to it, and have an extra icon: a lock. If that lock icon is pressed, the "(Private Course Material)" text will disapear, and an open-lock icon will replace the closed-lock icon. This indicates that the course is now unlocked, and available to everyone.

=== How it Works - Behind the Scenes ===

==== When a course is created: ====
#course members group is created
#private course material grouping is created
#course members group gets assigned to private course material
#all enrollees of that course are assigned to the course members group

==== When a resource/activity is added: ====
#groupmembersonly field is set to 1
#groupingid field is set to the grouping id that corresponds to the Private Course Material grouping for that particular course

==== When the closed lock icon is clicked: ====
#course material togles from being private->public
#groupmembersonly field is set to 0
#groupingid field is set to 0

==== When the closed lock icon is clicked: ====
#groupmembersonly field is set to 1
#groupingid field is set to the grouping id that corresponds to the Private Course Material grouping for that particular course

=== Code: Make Private ===
The below code demonstrates how to make a forum private. The same technique can be applied for any course module.

$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, $grouping_id);
set_coursemodule_groupmembersonly($course_module->id,1);

=== Code: Make Public ===
The below code demonstrates how to make a forum public. The same technique can be applied for any course module.
$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, 0);
set_coursemodule_groupmembersonly($course_module->id,0);

[[Category:Contributed code]]

Talk:PublicPrivate

2009-10-09T15:53:13Z

Moerderin:

Talk:PublicPrivate

2009-10-05T23:19:59Z

Moerderin: /* Don't think so but we're open to ideas */

Talk:PublicPrivate

2009-10-05T23:19:22Z

Moerderin: /* Don't think so but we're open to ideas */

Talk:PublicPrivate

2009-10-05T23:16:58Z

Moerderin: /* Don't think so but we're open to ideas */ new section

PublicPrivate

2009-07-14T21:21:05Z

Moerderin:

== Executive Summary ==

This page will spec out the features of Public/Private.

Public/Private is a means whereby any resource within moodle can be made private to only members of that course, or public and available to anyone that visits that site (including guests).

A practical use for this feature is making the syllabus public so that potential students can shop around for classes, but the rest of the course material is private and only available to the members of that course.

== Database structures ==
Below are the fields that are added to the already existing table.

=== course ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''groupautoassign'''
|BIGINT(10)
|0
|Group id to auto-assign members of the course.

|-
|'''grouppublicprivate'''
|TINYINT(1)
|0
|Whether public/private is enabled for that course.
|}

=== groups_members ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''type'''
|VARCHAR(36)
|NULL
|This field indicates whether the user was auto-assigned to a group, or not. (as opposed to manually added)
|}

== Overview of module communication ==

=== Setup ===
Setup is very simple. Once moodle is installed, All that needs to take place before using Public/Private is going into Administration->Miscellaneous->Experimental, and check both "Enable groupings", and "Enable Public/Private"

Now, create a course like normal, and add either a resource or activity to that course. The default behavior should be that when a resource or activity is added, it will read "(Private Course Material)" next to it, and have an extra icon: a lock. If that lock icon is pressed, the "(Private Course Material)" text will disapear, and an open-lock icon will replace the closed-lock icon. This indicates that the course is now unlocked, and available to everyone.

=== How it Works - Behind the Scenes ===

==== When a course is created: ====
#course members group is created
#private course material grouping is created
#course members group gets assigned to private course material
#all enrollees of that course are assigned to the course members group

==== When a resource is added: ====
#groupmembersonly field is set to 1
#groupingid field is set to the grouping id that corresponds to the Private Course Material grouping for that particular course

==== When the closed lock icon is clicked: ====
#course material togles from being private->public
#groupmembersonly field is set to 0
#groupingid field is set to 0

==== When the closed lock icon is clicked: ====
#groupmembersonly field is set to 1
#groupingid field is set to the grouping id that corresponds to the Private Course Material grouping for that particular course

=== Code: Make Private ===
The below code demonstrates how to make a forum private. The same technique can be applied for any course module.

$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, $grouping_id);
set_coursemodule_groupmembersonly($course_module->id,1);

=== Code: Make Public ===
The below code demonstrates how to make a forum public. The same technique can be applied for any course module.
$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, 0);
set_coursemodule_groupmembersonly($course_module->id,0);

PublicPrivate

2009-07-09T22:42:37Z

Moerderin: /* How it Works - Behind the Scenes */

== Executive Summary ==

This page will spec out the features of Public/Private.

Public/Private is a means whereby any resource within moodle can be made private to only members of that course, or public and available to anyone that visits that site (including guests).

A practical use for this feature is making the syllabus public so that potential students can shop around for classes, but the rest of the course material is private and only available to the members of that course.

== Database structures ==
Below are the fields that are added to the already existing table.

=== course ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''groupautoassign'''
|BIGINT(10)
|0
|Group id to auto-assign members of the course.

|-
|'''grouppublicprivate'''
|TINYINT(1)
|0
|Whether public/private is enabled for that course.
|}

=== groups_members ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''type'''
|VARCHAR(36)
|NULL
|This field indicates whether the user was auto-assigned to a group, or not. (as opposed to manually added)
|}

== Overview of module communication ==

TODO: describe the following:

=== Setup ===
Setup is very simple. Once moodle is installed, All that needs to take place before using Public/Private is going into Administration->Miscellaneous->Experimental, and check both "Enable groupings", and "Enable Public/Private"

Now, create a course like normal, and add either a resource or activity to that course. The default behavior should be that when a resource or activity is added, it will read "(Private Course Material)" next to it, and have an extra icon: a lock. If that lock icon is pressed, the "(Private Course Material)" text will disapear, and an open-lock icon will replace the closed-lock icon. This indicates that the course is now unlocked, and available to everyone.

=== How it Works - Behind the Scenes ===

==== When a course is created: ====
#course members group is created
#private course material grouping is created
#course members group gets assigned to private course material
#all enrollees of that course are assigned to the course members group

==== When a resource is added: ====
#groupmembersonly field is set to 1
#groupingid field is set to the grouping id that corresponds to the Private Course Material grouping for that particular course

==== When the closed lock icon is clicked: ====
#course material togles from being private->public
#groupmembersonly field is set to 0
#groupingid field is set to 0

==== When the closed lock icon is clicked: ====
#groupmembersonly field is set to 1
#groupingid field is set to the grouping id that corresponds to the Private Course Material grouping for that particular course

=== Code: Make Private ===
The below code demonstrates how to make a forum private. The same technique can be applied for any course module.

$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, $grouping_id);
set_coursemodule_groupmembersonly($course_module->id,1);

=== Code: Make Public ===
The below code demonstrates how to make a forum public. The same technique can be applied for any course module.
$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, 0);
set_coursemodule_groupmembersonly($course_module->id,0);

PublicPrivate

2009-07-09T22:42:21Z

Moerderin: /* when a course is created */

== Executive Summary ==

This page will spec out the features of Public/Private.

Public/Private is a means whereby any resource within moodle can be made private to only members of that course, or public and available to anyone that visits that site (including guests).

A practical use for this feature is making the syllabus public so that potential students can shop around for classes, but the rest of the course material is private and only available to the members of that course.

== Database structures ==
Below are the fields that are added to the already existing table.

=== course ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''groupautoassign'''
|BIGINT(10)
|0
|Group id to auto-assign members of the course.

|-
|'''grouppublicprivate'''
|TINYINT(1)
|0
|Whether public/private is enabled for that course.
|}

=== groups_members ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''type'''
|VARCHAR(36)
|NULL
|This field indicates whether the user was auto-assigned to a group, or not. (as opposed to manually added)
|}

== Overview of module communication ==

TODO: describe the following:

=== Setup ===
Setup is very simple. Once moodle is installed, All that needs to take place before using Public/Private is going into Administration->Miscellaneous->Experimental, and check both "Enable groupings", and "Enable Public/Private"

Now, create a course like normal, and add either a resource or activity to that course. The default behavior should be that when a resource or activity is added, it will read "(Private Course Material)" next to it, and have an extra icon: a lock. If that lock icon is pressed, the "(Private Course Material)" text will disapear, and an open-lock icon will replace the closed-lock icon. This indicates that the course is now unlocked, and available to everyone.

=== How it Works - Behind the Scenes ===

==== When a course is created: ====
#course members group is created
#private course material grouping is created
#course members group gets assigned to private course material
#all enrollees of that course are assigned to the course members group

==== When a resource is added ====
#groupmembersonly field is set to 1
#groupingid field is set to the grouping id that corresponds to the Private Course Material grouping for that particular course

==== When the closed lock icon is clicked ====
#course material togles from being private->public
#groupmembersonly field is set to 0
#groupingid field is set to 0

==== When the closed lock icon is clicked ====
#groupmembersonly field is set to 1
#groupingid field is set to the grouping id that corresponds to the Private Course Material grouping for that particular course

=== Code: Make Private ===
The below code demonstrates how to make a forum private. The same technique can be applied for any course module.

$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, $grouping_id);
set_coursemodule_groupmembersonly($course_module->id,1);

=== Code: Make Public ===
The below code demonstrates how to make a forum public. The same technique can be applied for any course module.
$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, 0);
set_coursemodule_groupmembersonly($course_module->id,0);

PublicPrivate

2009-07-09T22:41:21Z

Moerderin: /* How it Works - Behind the Scenes */

== Executive Summary ==

This page will spec out the features of Public/Private.

Public/Private is a means whereby any resource within moodle can be made private to only members of that course, or public and available to anyone that visits that site (including guests).

A practical use for this feature is making the syllabus public so that potential students can shop around for classes, but the rest of the course material is private and only available to the members of that course.

== Database structures ==
Below are the fields that are added to the already existing table.

=== course ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''groupautoassign'''
|BIGINT(10)
|0
|Group id to auto-assign members of the course.

|-
|'''grouppublicprivate'''
|TINYINT(1)
|0
|Whether public/private is enabled for that course.
|}

=== groups_members ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''type'''
|VARCHAR(36)
|NULL
|This field indicates whether the user was auto-assigned to a group, or not. (as opposed to manually added)
|}

== Overview of module communication ==

TODO: describe the following:

=== Setup ===
Setup is very simple. Once moodle is installed, All that needs to take place before using Public/Private is going into Administration->Miscellaneous->Experimental, and check both "Enable groupings", and "Enable Public/Private"

Now, create a course like normal, and add either a resource or activity to that course. The default behavior should be that when a resource or activity is added, it will read "(Private Course Material)" next to it, and have an extra icon: a lock. If that lock icon is pressed, the "(Private Course Material)" text will disapear, and an open-lock icon will replace the closed-lock icon. This indicates that the course is now unlocked, and available to everyone.

=== How it Works - Behind the Scenes ===

==== when a course is created ====
#course members group is created
#private course material grouping is created
#course members group gets assigned to private course material
#all enrollees of that course are assigned to the course members group

==== When a resource is added ====
#groupmembersonly field is set to 1
#groupingid field is set to the grouping id that corresponds to the Private Course Material grouping for that particular course

==== When the closed lock icon is clicked ====
#course material togles from being private->public
#groupmembersonly field is set to 0
#groupingid field is set to 0

==== When the closed lock icon is clicked ====
#groupmembersonly field is set to 1
#groupingid field is set to the grouping id that corresponds to the Private Course Material grouping for that particular course

=== Code: Make Private ===
The below code demonstrates how to make a forum private. The same technique can be applied for any course module.

$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, $grouping_id);
set_coursemodule_groupmembersonly($course_module->id,1);

=== Code: Make Public ===
The below code demonstrates how to make a forum public. The same technique can be applied for any course module.
$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, 0);
set_coursemodule_groupmembersonly($course_module->id,0);

PublicPrivate

2009-07-09T22:41:02Z

Moerderin: /* How it Works - Behind the Scenes */

== Executive Summary ==

This page will spec out the features of Public/Private.

Public/Private is a means whereby any resource within moodle can be made private to only members of that course, or public and available to anyone that visits that site (including guests).

A practical use for this feature is making the syllabus public so that potential students can shop around for classes, but the rest of the course material is private and only available to the members of that course.

== Database structures ==
Below are the fields that are added to the already existing table.

=== course ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''groupautoassign'''
|BIGINT(10)
|0
|Group id to auto-assign members of the course.

|-
|'''grouppublicprivate'''
|TINYINT(1)
|0
|Whether public/private is enabled for that course.
|}

=== groups_members ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''type'''
|VARCHAR(36)
|NULL
|This field indicates whether the user was auto-assigned to a group, or not. (as opposed to manually added)
|}

== Overview of module communication ==

TODO: describe the following:

=== Setup ===
Setup is very simple. Once moodle is installed, All that needs to take place before using Public/Private is going into Administration->Miscellaneous->Experimental, and check both "Enable groupings", and "Enable Public/Private"

Now, create a course like normal, and add either a resource or activity to that course. The default behavior should be that when a resource or activity is added, it will read "(Private Course Material)" next to it, and have an extra icon: a lock. If that lock icon is pressed, the "(Private Course Material)" text will disapear, and an open-lock icon will replace the closed-lock icon. This indicates that the course is now unlocked, and available to everyone.

=== How it Works - Behind the Scenes ===

==== when a course is created ====
+course members group is created
+private course material grouping is created
+course members group gets assigned to private course material
+all enrollees of that course are assigned to the course members group

==== When a resource is added ====
-groupmembersonly field is set to 1
-groupingid field is set to the grouping id that corresponds to the Private Course Material grouping for that particular course

==== When the closed lock icon is clicked ====
-course material togles from being private->public
-groupmembersonly field is set to 0
-groupingid field is set to 0

==== When the closed lock icon is clicked ====
-groupmembersonly field is set to 1
-groupingid field is set to the grouping id that corresponds to the Private Course Material grouping for that particular course

=== Code: Make Private ===
The below code demonstrates how to make a forum private. The same technique can be applied for any course module.

$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, $grouping_id);
set_coursemodule_groupmembersonly($course_module->id,1);

=== Code: Make Public ===
The below code demonstrates how to make a forum public. The same technique can be applied for any course module.
$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, 0);
set_coursemodule_groupmembersonly($course_module->id,0);

PublicPrivate

2009-07-09T22:40:33Z

Moerderin: /* How it Works - Behind the Scenes */

== Executive Summary ==

This page will spec out the features of Public/Private.

Public/Private is a means whereby any resource within moodle can be made private to only members of that course, or public and available to anyone that visits that site (including guests).

A practical use for this feature is making the syllabus public so that potential students can shop around for classes, but the rest of the course material is private and only available to the members of that course.

== Database structures ==
Below are the fields that are added to the already existing table.

=== course ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''groupautoassign'''
|BIGINT(10)
|0
|Group id to auto-assign members of the course.

|-
|'''grouppublicprivate'''
|TINYINT(1)
|0
|Whether public/private is enabled for that course.
|}

=== groups_members ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''type'''
|VARCHAR(36)
|NULL
|This field indicates whether the user was auto-assigned to a group, or not. (as opposed to manually added)
|}

== Overview of module communication ==

TODO: describe the following:

=== Setup ===
Setup is very simple. Once moodle is installed, All that needs to take place before using Public/Private is going into Administration->Miscellaneous->Experimental, and check both "Enable groupings", and "Enable Public/Private"

Now, create a course like normal, and add either a resource or activity to that course. The default behavior should be that when a resource or activity is added, it will read "(Private Course Material)" next to it, and have an extra icon: a lock. If that lock icon is pressed, the "(Private Course Material)" text will disapear, and an open-lock icon will replace the closed-lock icon. This indicates that the course is now unlocked, and available to everyone.

=== How it Works - Behind the Scenes ===

==== when a course is created ====
-course members group is created
-private course material grouping is created
-course members group gets assigned to private course material
-all enrollees of that course are assigned to the course members group

==== When a resource is added ====
-groupmembersonly field is set to 1
-groupingid field is set to the grouping id that corresponds to the Private Course Material grouping for that particular course

==== When the closed lock icon is clicked ====
-course material togles from being private->public
-groupmembersonly field is set to 0
-groupingid field is set to 0

==== When the closed lock icon is clicked ====
-groupmembersonly field is set to 1
-groupingid field is set to the grouping id that corresponds to the Private Course Material grouping for that particular course

=== Code: Make Private ===
The below code demonstrates how to make a forum private. The same technique can be applied for any course module.

$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, $grouping_id);
set_coursemodule_groupmembersonly($course_module->id,1);

=== Code: Make Public ===
The below code demonstrates how to make a forum public. The same technique can be applied for any course module.
$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, 0);
set_coursemodule_groupmembersonly($course_module->id,0);

PublicPrivate

2009-07-09T22:39:51Z

Moerderin: /* How it Works - Behind the Scenes */

== Executive Summary ==

This page will spec out the features of Public/Private.

Public/Private is a means whereby any resource within moodle can be made private to only members of that course, or public and available to anyone that visits that site (including guests).

A practical use for this feature is making the syllabus public so that potential students can shop around for classes, but the rest of the course material is private and only available to the members of that course.

== Database structures ==
Below are the fields that are added to the already existing table.

=== course ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''groupautoassign'''
|BIGINT(10)
|0
|Group id to auto-assign members of the course.

|-
|'''grouppublicprivate'''
|TINYINT(1)
|0
|Whether public/private is enabled for that course.
|}

=== groups_members ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''type'''
|VARCHAR(36)
|NULL
|This field indicates whether the user was auto-assigned to a group, or not. (as opposed to manually added)
|}

== Overview of module communication ==

TODO: describe the following:

=== Setup ===
Setup is very simple. Once moodle is installed, All that needs to take place before using Public/Private is going into Administration->Miscellaneous->Experimental, and check both "Enable groupings", and "Enable Public/Private"

Now, create a course like normal, and add either a resource or activity to that course. The default behavior should be that when a resource or activity is added, it will read "(Private Course Material)" next to it, and have an extra icon: a lock. If that lock icon is pressed, the "(Private Course Material)" text will disapear, and an open-lock icon will replace the closed-lock icon. This indicates that the course is now unlocked, and available to everyone.

=== How it Works - Behind the Scenes ===

skeleton:
when a course is created:
-course members group is created
-private course material grouping is created
-course members group gets assigned to private course material
-all enrollees of that course are assigned to the course members group

When a resource is added:
-groupmembersonly field is set to 1
-groupingid field is set to the grouping id that corresponds to the Private Course Material grouping for that particular course

When the closed lock icon is clicked:
-course material togles from being private->public
-groupmembersonly field is set to 0
-groupingid field is set to 0

When the closed lock icon is clicked:
-groupmembersonly field is set to 1
-groupingid field is set to the grouping id that corresponds to the Private Course Material grouping for that particular course

=== Code: Make Private ===
The below code demonstrates how to make a forum private. The same technique can be applied for any course module.

$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, $grouping_id);
set_coursemodule_groupmembersonly($course_module->id,1);

=== Code: Make Public ===
The below code demonstrates how to make a forum public. The same technique can be applied for any course module.
$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, 0);
set_coursemodule_groupmembersonly($course_module->id,0);

PublicPrivate

2009-07-09T22:31:00Z

Moerderin: /* Overview of module communication */

== Executive Summary ==

This page will spec out the features of Public/Private.

Public/Private is a means whereby any resource within moodle can be made private to only members of that course, or public and available to anyone that visits that site (including guests).

A practical use for this feature is making the syllabus public so that potential students can shop around for classes, but the rest of the course material is private and only available to the members of that course.

== Database structures ==
Below are the fields that are added to the already existing table.

=== course ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''groupautoassign'''
|BIGINT(10)
|0
|Group id to auto-assign members of the course.

|-
|'''grouppublicprivate'''
|TINYINT(1)
|0
|Whether public/private is enabled for that course.
|}

=== groups_members ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''type'''
|VARCHAR(36)
|NULL
|This field indicates whether the user was auto-assigned to a group, or not. (as opposed to manually added)
|}

== Overview of module communication ==

TODO: describe the following:

=== Setup ===
Setup is very simple. Once moodle is installed, All that needs to take place before using Public/Private is going into Administration->Miscellaneous->Experimental, and check both "Enable groupings", and "Enable Public/Private"

Now, create a course like normal, and add either a resource or activity to that course. The default behavior should be that when a resource or activity is added, it will read "(Private Course Material)" next to it, and have an extra icon: a lock. If that lock icon is pressed, the "(Private Course Material)" text will disapear, and an open-lock icon will replace the closed-lock icon. This indicates that the course is now unlocked, and available to everyone.

=== How it Works - Behind the Scenes ===

=== Code: Make Private ===
The below code demonstrates how to make a forum private. The same technique can be applied for any course module.

$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, $grouping_id);
set_coursemodule_groupmembersonly($course_module->id,1);

=== Code: Make Public ===
The below code demonstrates how to make a forum public. The same technique can be applied for any course module.
$grouping_id = groups_get_grouping_publicprivate($COURSE->id);
$course_module = get_record("course_modules", "instance", $forum->id, "course", $COURSE->id);
set_coursemodule_groupingid($course_module->id, 0);
set_coursemodule_groupmembersonly($course_module->id,0);

PublicPrivate

2009-07-09T21:48:01Z

Moerderin: /* groups_members */

PublicPrivate

2009-07-09T21:45:46Z

Moerderin: /* groups_members */

PublicPrivate

2009-07-09T20:43:10Z

Moerderin: /* Database structures */

PublicPrivate

2009-07-09T20:37:15Z

Moerderin: /* Database structures */

PublicPrivate

2009-07-09T20:35:16Z

Moerderin: /* course */

PublicPrivate

2009-07-09T20:34:44Z

Moerderin: /* Database structures */

PublicPrivate

2009-07-09T18:57:34Z

Moerderin: /* Overview of module communication */

PublicPrivate

2009-07-09T18:57:08Z

Moerderin: New page: == Executive Summary == This page will spec out the features of Public/Private. Public/Private is a means whereby any resource within moodle can be made private to only members of that ...