Re: Two complex scenarios

Hi John,

> Hi Nagy:
> 
> In message <20210317110315.4bf1528f@Dell>,
> Nagy Gabor writes:
> >1. Search in more than one classes at the same time. Typical use
> >case: For example, there are bug, issue and task classes in the
> >tracker, and it is convenient to collect the list "bugs/issues/tasks
> >assigned to me" to one page, instead of forcing the user to click 3
> >buttons. I am not sure what I want at this point, first I played
> >with the renderWith method, but it leads to too much restrictions,
> >so I think I should use the db variable and the batching capability
> >of the web interface. However, any working examples (as a guide)
> >would be appreciated. :)  
> 
> How different are these classes? If they have the same properties, it
> may be better to structure your schema with a "type" field with the
> values bugs, issues, tasks and just perform a search on one class.

Yes, I was also thinking about this: The two classes have some common
properties, but not all (roughly 50% of the properties of one class
exists in the other class). However, some items of ClassA are linked to
items of ClassB (which represents a parent-child relation), and these
pairs would fit better in the common class (and would reduce some
duplication of data). But in the end, I thought two different Classes
would be easier to work with instead of always setting a filter on
type. Well, now I am not so sure... :)

Btw, I've implemented this parent-child links using rev_multilink. I
think this is a great functionality, and I am surprised that it is not
used in default templates. Is there any disadvantages of that? (I am
even considering using Multilink(..., rev_multilink=...) on FileClass
to track the owner(s) of files to easily filter orphans.)

> I assume the way you have used renderWith is to create a new action
> (say searchAllClasses) and try to use renderWith modifying self to
> iterate over each class. This is tough as roundup really expects a
> single class as its context and using multiple contexts is difficult.
> 
> You may be able to submit the search to the home context and create a
> home.dashboard.html and use @template=dashboard. This means you don't
> call renderWith at all. You will probably have to create extensions to
> perform the search as you won't be able to use request/batch (as you
> aren't in a class context). So you would have three sections and in
> the issue section something like:
> 
>   <tal:block tal:define="batch
> python:utils.searchissue_extension(request.???)"
> tal:condition="context/is_view_ok">  
> 
> what request parameter (if any) to pass to your
> utils.searchissue_extension() is left as an exercise for the reader.
> 
> Another possibly is to use the rest interface to build this view
> client side using the rest interface and something like react, angular
> or reef to compose the data into a dashboard.
> 
> >2. I want to allow users to send emails (with some preloaded content
> >from the roundup database). As a first try, I've created an extension
> >to the web interface: a new 'email' action, which first sends the
> >email (the required information is in form variables, set by an
> >email-editor html template), and if the sending is successful then
> >call the core EditItemAction, which adds the content of the email to
> >the database (as an msg). Everything works as expected, but
> >difficulties arise if I want to allow the users to upload
> >attachments... I do not know how to handle this in my 'email'
> >action.  
> 
> Maybe look at how @file works for create/edit action and implement
> @file in your email action. This will create the files in the
> database, add the html as a message and send the whole thing. (I don't
> remember if the default notification email sends attachments on update
> or not.)
> 
> >I can do this by druid templating (add a
> >button "Upload attachments" to the email editor page, which commits
> >the files to the db somewhere, and the real 'email' action can
> >already use the uploaded files). Or this whole email sending stuff
> >can be moved to a reactor: First commit everything to the db, and
> >the reactor sends the email.  
> 
> Roundup does it in the nosy reactor. You shouldn't be sending email
> before things are committed to the database. Taking email and other
> actions before the auditors have run and allowed the updated data into
> the db makes it impossible to filter/limit updates. E.G. you may have
> a requirement that url's in email are only allowed to start with
> "https//my.company.com". AFAIK there is no way to use the auditor to
> validate this as it only runs as part of the commit to the hyperdb.

Well, this is a good point...

> >I do not know which version is better (for example,
> >user's browser should not timeout, while Roundup is sending email),
> >email action seems more logical to me (first send, then if it
> >successful, then add to the db - no database spam on unsuccessful
> >emails),  
> 
> Email is a queue, store and forward mechanism. Emails can be
> succesfully sent to the first hop and and you won't know it's failed
> for hours. Emails can go through 2 or three relays before they bounce.
> 
> Have a great week.

Gábor

> --
> 				-- rouilj
> John Rouillard
> ===========================================================================
> My employers don't acknowledge my existence much less my opinions.
> 
> 
> _______________________________________________
> Roundup-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/roundup-users


_______________________________________________
Roundup-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/roundup-users