[Sugar-devel] [Moodle]About the has_capability() function

[Vamsi Krishna Davuluri]

Hi Martin,
I am sold with the blocks concept ;)

Though:

I have finally wrapped things with the XML-RPC stuff for assignment-clone
(which is print) module
My idea was "do anything new only after having a backup". But there's still
the authentication stuff
that's at question. How do i tell moodle this is from an user X and how do I
tell moodle that this will
go into a particular course module ( I see no way to beat this without
having  a selection UI in the
client).
I have attached the module. There's a test.php script you can run to check
how the xmlr-rpc code
works.
And I am very well ready to do a switch to a block, provided I have this
all setup, so I don't mess my GSoC schedule.
;)

Thanks,
Vamsi
On Fri, Jul 17, 2009 at 1:56 PM, Martin Langhoff
<martin.langhoff at gmail.com>wrote:

> Hi Vamsi,
>
> Good hint from Tim -- Using a block is a much better approach :-) --
> blocks are also "for something else" but we can make it happen if we
> are careful about a couple of things...
>
> So it's good to make a new block. I assume you can look at the block
> guide a bit, and draft a simple initial block -- do ask for help if
> you get stuck in that.
>
> I trust you to design how it works :-)
>
> There are acouple of "special" things I think you want to be careful
> with, because we are not making a conventional block.
>
> These are tricky points. I read my own email 3 times to make sure it
> made sense :-)
>
> I am also copying Mihai Suncan - he is working on a different project
> that (I suspect) has to solve a similar problem (in #2 below).
>
> 1 - Blocks can be displayed in any 'course page'. In our case, it will
> usualyl be displayed in the "Homepage" (which is a course page,
> actually, the course page of a special course that is called the
> 'sitecourse', identified by the SITEID constant). If it is displayed
> in a conventional course page (non-'sitecourse') it should probably
> show the same data.
>
> So the _context_ (in terms of access control API) in which it is
> displayed does not matter much -- it is a matter of convenience to the
> user. So you want to mostly _ignore_ the context that the Blocks API
> gives you, and make a lookup for the context of the "system context".
> You want to ask whether the user has printing / print-queue-management
> rights in the system context, instead of in the course context.
>
> 2 - You will need to transfer the data from the Journal to Moodle,
> store it somewhere, one of the key things is "in which security
> context / in which course". The other one is "how to handle the
> transfer".
>
> 2.1 - For the security context / "which course" question, my
> recommendation is to use the 'sitecourse' in Moodle 1.9.x -- this is
> not entirely correct, but I think we can make it work. We need to look
> up exactly how we can store those files in a way that is private for
> each user (so they are not browsable by anyone on the 'files' UI).
>
> For 2.0 (and for 1.9.x if the above doesn't work) we need to catch up
> with Petr to see how "user" files are handled in the new Files API.
> If/when we go this way, we will want to use the 'CONTEXT_USER'
> context. If things are not ready in the API, it will be awkward.
>
> 2.2 - The transfer! Moodle's existing API won't give you much here,
> neither in 1.9.x or in 2.0, but there are good tools to do what we
> want.
>
> 2.2.1 You _will need to make a specific entry point to transfer the
> files to_, a URL inside the block directory. We don't want to hardcode
> that in the Journal side, so let's hardcode a canonical URL in the
> Journal ( http://schoolserver/printqueue ) and we'll use a redirect or
> an alias to point it to the right file in your Moodle block.
>
> 2.2.2 The files to print can be large -- very large. HTTP is not very
> good transferring very large files, and Apache+PHP on the server side
> only make it worse (in memory use in particular). I am being polite
> here -- it sucks. It's unworkable.
>
> One thing we can do is to use WebDAV which is HTTP but it has all the
> smarts needed to transfer large files in many little chunks.
>
> One the Journal side, you need to identify a good python lib that can
> talk WebDAV. Does not need to be fancy but you _will_ want something
> that has a big "turn on debugging" option so you can see what's
> happening :-)
>
> On the Moodle side, we can use the PHP WebDAV libs to make a "magic"
> webdav folder that acts as a "blind dropbox"... a directory that looks
> always empty, but that you can transfer files to (and returns an OK
> code when the transfer succeeds).
>
> I wrote a "Moodle WebDAV" patch about 2 years ago that can be a good
> source of inspiration. My patch does a ton more, so you only need...
> 5% of it.
>
> hth,
>
>
>
> martin
>
>
> On Tue, Jul 14, 2009 at 5:18 PM, Vamsi Krishna
> Davuluri<vdavuluri at acm.org> wrote:
> >
> > I finished writing a course module, but anyway. I
> > I talked to Tim Hunt from Moodle.
> > And we had a very lengthy discussion to port this into a Block.
> > A block would have the advantage of being used anywhere from
> > moodle, and also enable us to  have global notifications.
> > This seems much appropriate.
> >
> > 12:21:45 PM) Vamsi Krishna D: http://pastebin.be/19720
> > (12:26:55 PM) Tim Hunt: Great!
> > (12:27:48 PM) Tim Hunt: So one question, is how does the teacher get to
> the
> > 'Print submissions page'. Presumably that is a link, but where is the
> best
> > place for it in Moodle.
> > (12:27:56 PM) Tim Hunt: ?
> > (12:29:04 PM) Vamsi Krishna D: he would have to enter the activity in my
> > vision. But I suspect having it in his global notifications would be best
> > (12:29:33 PM) Tim Hunt: Yes. I think using a block lets you put the
> global
> > notification on any page.
> > (12:30:45 PM) Tim Hunt: My feeling is that this whole system should be
> > loosely coupled to Moodle, and an assignment must be strongly coupled to
> a
> > course.
> > (12:31:00 PM) Vamsi Krishna D: Okay, can i reuse any of my code :p
> > (12:31:34 PM) Tim Hunt: Sure. I think the code that does the actual work
> is
> > the same, it is just a question of where you put it.
> > (12:31:46 PM) Tim Hunt: The code for integrating to Moodle would be
> > different.
> > (12:32:45 PM) Tim Hunt: The good thing about blocks is that there is
> quite
> > good documentation for how to make one:
> > http://dev.moodle.org/course/view.php?id=2 and
> > http://docs.moodle.org/en/Development:Blocks
> > (12:34:12 PM) Tim Hunt: I suggest that the block just gives a summary
> like
> > '3 print jobs awaiting approval' with a link to a separate
> > blocks/printingmanager/approve.php script that does most of the work.
> > (12:34:49 PM) Vamsi Krishna D: so that would be like my submissions.php?
> > (12:34:59 PM) Tim Hunt: And for students the block can have a link,
> > something like 'Upload your print jobs here that takes them to a
> > blocks/printingmanager/submit.php
> > (12:35:22 PM) ***Tim Hunt goes to look at submissions.php
> > (12:35:53 PM) Vamsi Krishna D: which calls a function submissions.php in
> > lib.php :p
> > (12:36:00 PM) Vamsi Krishna D: submissions()
> > (12:36:01 PM) Vamsi Krishna D: *
> > (12:36:22 PM) Tim Hunt: Well, submissions.php has lots of code specific
> to
> > being an assignment in a course. Most of that could be deleted if this is
> a
> > separate script linked to from a block ;-)
> > (12:36:52 PM) Vamsi Krishna D: Ah!
> > (12:37:12 PM) Tim Hunt: Yes, it looks like you could move the code from
> > submissions() to blocks/printingmanager/approve.php - or whatever you
> want
> > to call it.
> > (12:37:56 PM) Vamsi Krishna D: excellent!
> > (12:38:33 PM) Vamsi Krishna D: Martin was also suggesting something
> better
> > than Course modules
> > (12:38:45 PM) Tim Hunt: What did Martin suggest?
> > (12:39:24 PM) Vamsi Krishna D: In my opinion, your code should not be a
> > moodle module. We need to
> > organize a skype / sip / irc chat to discuss where it would 'fit' in
> > Moodle. There are other APIs in Moodle that may be a better place.
> >
> > Or perhaps it doesn't fit any API and we need to craft a patch.
> > (12:40:03 PM) Tim Hunt: Ah I think I have not said anything that Martin
> > woudl disagree with ;-)
> > (12:40:17 PM) Vamsi Krishna D: Great!
> > (12:40:32 PM) Tim Hunt: The only other option I can think of is to put
> your
> > code in the /local folder, which is designed for miscellaneous hacks.
> > (12:40:40 PM) Tim Hunt: However, I think a block is better.
> > (12:41:05 PM) Tim Hunt: But might be worth emailing Martin a summary of
> what
> > we talked about, to make sure he agrees with what I have said.
> > (12:41:09 PM) Vamsi Krishna D: let me mail Martin and my mentor about
> this
> > concept
> >
> > On Tue, Jul 14, 2009 at 5:57 AM, Martin Langhoff <
> martin.langhoff at gmail.com>
> > wrote:
> >>
> >> On Thu, Jul 9, 2009 at 1:15 PM, Vamsi Krishna
> >> Davuluri<vamsi.davuluri at gmail.com> wrote:
> >> > Thanks to a kick start from Andres, I'm working royally with
> >> > moodle.
> >>
> >> Excellent. Sorry about taking so long.
> >>
> >> > so anyway, despite reading the reference site on the function:
> >> > I couldn't figure out how it works.
> >> >
> >> > has_capability('mod/print:submit', $this->context)
> >> > how exactly does this function work?
> >>
> >> Let me see if I can shed some light...
> >>
> >>  - A module is _always_ used as part of a course. Modules implement
> >> the behaviour of a 'module instance', (think of it in OOP terms). So
> >> for example mod/forum code handles "a forum in a course", which is a
> >> "modinstance"  (module instance) in moodle internals lingo.
> >>
> >>  - Each modinstance has a "security context" - sec contexts are
> >> nested, like this: Site -> Category -> Course -> Modinstance.
> >>
> >>  - The $context object you have there refers to the context of the
> >> specific modinstance you are dealing with (again, in OOP-ish terms,
> >> though moodle's modules aren't strictly OOP).
> >>
> >> With that background laid out, the code
> >>
> >>   has_capability('mod/print:submit', $this->context)
> >>
> >> will return true or false answering the following question:
> >>
> >>     does the currently logged in user have the
> >>     capability/authorization to do "mod/print:submit"
> >>     in the context of this module instance?
> >>
> >> Now, this won't make much sense in your case because printing is not
> >> about stuff "in a course".
> >>
> >> In my opinion, your code should not be a moodle module. We need to
> >> organize a skype / sip / irc chat to discuss where it would 'fit' in
> >> Moodle. There are other APIs in Moodle that may be a better place.
> >>
> >> Or perhaps it doesn't fit any API and we need to craft a patch.
> >>
> >> cheers,
> >>
> >>
> >>
> >> m--
> >>  martin.langhoff at gmail.com
> >>  martin at laptop.org -- School Server Architect
> >>  - ask interesting questions
> >>  - don't get distracted with shiny stuff  - working code first
> >>  - http://wiki.laptop.org/go/User:Martinlanghoff
> >
> >
>
>
>
> --
>  martin.langhoff at gmail.com
>  martin at laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090731/7a7fcbcc/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: print_1.tar.gz
Type: application/x-gzip
Size: 108651 bytes
Desc: not available
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090731/7a7fcbcc/attachment-0001.bin