Re: Help me develop a Job Tracker (?)

[Softeisbieger]

On Thursday, July 2, 2015 at 6:04:57 PM UTC+2, Javier Guerra wrote:

> good luck! 
>
> -- 
> Javier 
>

Thanks for your input! Indeed, a linear pipeline should be sufficient. What 
do you think of my idea of organizing this in two database tables? One 
table models a work flow. A work flow points to the currently active task 
in another table. Each task has information about its predecessor / 
successor. In principle like a doubly-linked list. This solution feels a 
bit brittle / hacked to me. Again, my reason is, I want to store all the 
work flows with this standard interface. Also, users can easily create new 
work flows with any number of steps. Maybe there is a better way?

In case you are interested: I wrote earlier that I am developing this for a 
landscape gardening company. Since the company grew quite a bit recently 
and more people are working in administration, it is necessary to organize 
the flow of jobs: Quickly see who is responsible, what is currently 
happening, which jobs are overdue. Also each job is touched by different 
people (something like acquisition -> execution -> accounting) and the 
framework should organize this as well. There are different work flows for 
example to execute work and to make a quotation. Until now this is 
organized using a combination of paper and memory which is not feasible 
anymore. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/4576fa8b-b19f-4348-b254-1e7cbf581cc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help me develop a Job Tracker (?)

[Javier Guerra Giraldez]

On Fri, Jul 3, 2015 at 2:50 AM, Softeisbieger  wrote:
> Thanks for your input! Indeed, a linear pipeline should be sufficient. What
> do you think of my idea of organizing this in two database tables? One table
> models a work flow. A work flow points to the currently active task in
> another table. Each task has information about its predecessor / successor.
> In principle like a doubly-linked list. This solution feels a bit brittle /
> hacked to me. Again, my reason is, I want to store all the work flows with
> this standard interface. Also, users can easily create new work flows with
> any number of steps. Maybe there is a better way?


i don't think a linked list is appropriate for databases.   the
simplest design would be:  a Workflow model to identify it (with id,
name, creator, that kind of things), and a Step model that 'belongs'
to the Workflow something like this:

class Workflow(models.model):
   name = models.charfield()

class Step(models.model):
workflow = models.ForeignKeyField(Workflow)
name = models.charfield()
order = models.SmallIntegerField()
taskdescriiption = models.TextField()

class Meta:
ordering = ['workflow','order']

def previous(self):
return self.workflow.step_set.filter(order_lt=self.order)[-1]

def next(self):
return self.workflow.step_set.filter(order_gt=self.order)[0]


those two models keep the definition of a workflow.  then, define the
'working' models, one for a whole project, and other for each task to
perform:

class Project(models.model):
name = models.charfield()
workflow = models.ForeignKeyField(Workflow)
responsible = models.ForeignKeyField(User)
deadline = models.DatetimeField()

def started_tasks(self):
return self.task_set.filter(start__isnull=False)

def finished_tasks(self):
return self.task_set.filter(finish__isnull=False)

def in_process_tasks(self):
return self.task_set.filter(start__isnull=False, finish__isnull=True)

def finished(self):
return self.started_tasks.exist() and not self.in_process_task.exist()

class Task(models.model):
project = models.ForeignKeyField(Task)
step = models.ForeignKeyField(Step)
deadline = models.DatetimeField()
assigned_to  = models.ForeignKeyField(User, blank=True, null=True)
start = models.DatetimeField(blank=True, null=True)
finish = models.DatetimeField(blank=True, null=True)


in most cases, it's better not to have a 'current task' pointer.  just
some tasks that have been started but not finished(yet).  it's up to
you to decide if it's appropriate to have more than one task in
process for a given project, or if it's valid to start a task before
some of the previous tasks.

usually it's also nice to add action methods to some models, maybe a
project.start(user) that creates the first task and starts it, and a
project.next(user) that finishes a task and creates/starts the next
one (if there's any more step(s)).

-- 
Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFkDaoTOXLOiSM0ctV%2BBWaPjSp24qv4QF5Ux0ZwsaZ90wLb3vA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

is it safe to use ModelAdmin variables like this

[Zaher Sarieddine]

Is it safe to set a modeladmin variable and use it like this; it is set in 
the changelist_view based on the url search criteria and is used to limit 
the choices of a foreign key when adding new item

class MyModelAdmin(reversion.VersionAdmin):
...
selected_period = None

def formfield_for_foreignkey(self, db_field, request, **kwargs):
if db_field.name == "period":
kwargs["queryset"] = Period.objects.filter(id=self.selected_period)
return super(MyModelAdmin, self).formfield_for_foreignkey(db_field, 
request, **kwargs)

def changelist_view(self, request, extra_context=None):
   ..
if request.GET.has_key('period__id__exact'):
self.selected_period = request.GET['period__id__exact']
return super(MyModelAdmin, self).changelist_view(request, 
extra_context=extra_context)
admin.site.register(MyClassroomAbsenceLog, MyClassroomAbsenceLogAdmin)


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/02120fbc-8f78-4d65-b0b8-d503434b8f6f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django model for non web applications

[Vernon D. Cole]

Jeff:
   I think that Russell's answer might be more appropriate for your use 
case than Carl's.  django.setup() calls settings.configure(), but also 
tries to pull in other application modules, which you might not want.


On Thursday, July 2, 2015 at 6:50:20 PM UTC-6, Carl Meyer wrote:
>
> On 07/02/2015 05:49 PM, Russell Keith-Magee wrote: 
> > 
> > On Thu, Jul 2, 2015 at 12:50 AM, Jeff Fritz   
> > > wrote: 
> > 
> > I'm fairly new to Django and making my way through the tutorial. 
> > 
> > Knowing what I've learned so far, I'd like to explore using 
> > django.db.models.Model in a non-web application. I'd like to take 
> > the entire model layer and use it for database access in a 
> > standalone, multithreaded python 3.4 application. It is not a web 
> > application. I would like to be able to take advantage of the 
> > migration capabilities in manage.py. 
> > 
> > Questions: 
> > 
> > 1. Is it as simple as adding `from djanago.db import models`? Would 
> > this bring in any unnecessary django packages/modules, considering I 
> > will not be developing a web application, not using views, 
> > templating, etc? 
> > 
> > 
> > It's *almost* this simple - you will also need to configure your Django 
> > environment before you start making database calls. If you're looking to 
> > do this in a *completely* "non-web" way, this probably means a call to 
> > settings.configure(); details here: 
> > 
> > https://docs.djangoproject.com/en/1.8/topics/settings/ 
>
> Don't forget that in Django 1.7+ you also need to call django.setup() 
> yourself, if using Django outside the context of a WSGI server or 
> management command: 
> https://docs.djangoproject.com/en/1.8/ref/applications/#django.setup 
>
> Carl 
>
> >   
> > 
> > 2. Is the django model layer thread safe? Specifically, when using 
> > sqlite3 as a back end? 
> > 
> > 
> > It should be - after all, web servers are frequently multi-threaded. 
> > SQLite3's performance under multithreading, however, might leave 
> > something to be desired. 
> >   
> > 
> > 3. Are there other clean ORM/database model layer 
> > frameworks/packages that I should consider for python 3.4? 
> > 
> >   
> > The other obvious candidate would be SQLAlchemy; it's a perfectly fine 
> > ORM - without any of the other web framework overhead. It's a lot more 
> > like a "SQL building toolkit" than Django's ORM - whether this is a good 
> > or bad thing depends on your own preferences and use case. 
> > 
> > Yours, 
> > Russ Magee %-) 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/05d20585-bf6e-4c1f-8014-2ea19e2d7aa0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django model for non web applications

[Carl Meyer]

On 07/03/2015 07:46 AM, Vernon D. Cole wrote:
> Jeff:
>I think that Russell's answer might be more appropriate for your use
> case than Carl's.  django.setup() calls settings.configure(), but also
> tries to pull in other application modules, which you might not want.

No, `settings.configure()` and `django.setup()` are not alternatives.
They are _both_ needed for Jeff's use case (depending on how he wants to
handle settings). `settings.configure()` is one option for settings;
`django.setup()` is required no matter what (since Django 1.7).

Settings can be handled either via the usual Python settings module, in
which case the DJANGO_SETTINGS_MODULE env var needs to be set to the
import path to this module, or they can be handled by calling
`settings.configure()` with a dict of the desired settings.

One of those two things needs to be done before calling
`django.setup()`. `setup()` does not "call settings.configure()" - it
loads settings, which requires either that `settings.configure()` has
already been called, or that DJANGO_SETTINGS_MODULE is set.

And yes, `django.setup()` also loads installed applications. Since
Django 1.7, this is required in order to use the ORM (which is the core
of Jeff's use case).

Carl

> 
> 
> On Thursday, July 2, 2015 at 6:50:20 PM UTC-6, Carl Meyer wrote:
> 
> On 07/02/2015 05:49 PM, Russell Keith-Magee wrote:
> >
> > On Thu, Jul 2, 2015 at 12:50 AM, Jeff Fritz  
> > > wrote:
> >
> > I'm fairly new to Django and making my way through the tutorial.
> >
> > Knowing what I've learned so far, I'd like to explore using
> > django.db.models.Model in a non-web application. I'd like to take
> > the entire model layer and use it for database access in a
> > standalone, multithreaded python 3.4 application. It is not a web
> > application. I would like to be able to take advantage of the
> > migration capabilities in manage.py.
> >
> > Questions:
> >
> > 1. Is it as simple as adding `from djanago.db import models`?
> Would
> > this bring in any unnecessary django packages/modules,
> considering I
> > will not be developing a web application, not using views,
> > templating, etc?
> >
> >
> > It's *almost* this simple - you will also need to configure your
> Django
> > environment before you start making database calls. If you're
> looking to
> > do this in a *completely* "non-web" way, this probably means a
> call to
> > settings.configure(); details here:
> >
> > https://docs.djangoproject.com/en/1.8/topics/settings/
> 
> 
> Don't forget that in Django 1.7+ you also need to call django.setup()
> yourself, if using Django outside the context of a WSGI server or
> management command:
> https://docs.djangoproject.com/en/1.8/ref/applications/#django.setup
> 
> 
> Carl
> 
> >  
> >
> > 2. Is the django model layer thread safe? Specifically, when
> using
> > sqlite3 as a back end?
> >
> >
> > It should be - after all, web servers are frequently multi-threaded.
> > SQLite3's performance under multithreading, however, might leave
> > something to be desired.
> >  
> >
> > 3. Are there other clean ORM/database model layer
> > frameworks/packages that I should consider for python 3.4?
> >
> >  
> > The other obvious candidate would be SQLAlchemy; it's a perfectly
> fine
> > ORM - without any of the other web framework overhead. It's a lot
> more
> > like a "SQL building toolkit" than Django's ORM - whether this is
> a good
> > or bad thing depends on your own preferences and use case.
> >
> > Yours,
> > Russ Magee %-)
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users+unsubscr...@googlegroups.com
> .
> To post to this group, send email to django-users@googlegroups.com
> .
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/05d20585-bf6e-4c1f-8014-2ea19e2d7aa0%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-

Re: Django formset hidden id field

[Peter of the Norse]

> On Jul 2, 2015, at 7:46 PM, Carl Meyer  wrote:
> 
>> So what?  It’s quite likely that whoever is editing this row of the
>> database, also has permissions to edit the other rows as well.  There’s
>> no reason for them to go through the hassle of manually editing a hidden
>> field when they can go to a different page and edit it there.
> 
> That's a bad answer. It's common in many systems for a user to have
> access to edit some records in a table but not others (this is often
> known as "object-level permissions"). If it was really possible to edit
> any row in the table by just manually editing the PK hidden field, that
> would be a serious security flaw in formsets.
> 
> But it's not. Whatever queryset you pass to the model formset limits the
> available rows for editing. The end user can edit the PK to refer to any
> item in that queryset, but not any item in the table.
> 
>> In general, primary keys are not security flaws.  While it’s a good idea
>> to hide them from front-end pages, that’s mostly because they make URLs
>> hard to read.  I have heard that you don’t want to use them publicly,
>> because your competitors can use them to gauge your success, but that’s
>> the kind of “Nice Problem to Have” that can wait until you’re bigger.
> 
> Exposing primary keys themselves (e.g. in URLs) is not necessarily a
> security flaw. Exposing a primary key in a hidden field that can be
> edited to change a form to edit any row in a table often would be a
> serious security flaw.

You can’t have it both ways. Either exposing the PK is a security flaw or it 
isn’t. It’s just as easy for nefarious n’er-do-wells to edit the form’s URL as 
a hidden field. In either case, if you are using object-level permissions, more 
checks (not made automatic in Django) are necessary. Having the ID passed as a 
parameter doesn’t necessitate, hinder, or alleviate running these checks.

If you can come up with a method that associates form data with a database row 
that doesn’t involve the PK, I would love to know. Keep in mind that most 
tables only have the one unique identifier.

Peter of the Norse
rahmc...@radio1190.org



-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/F9FAB5F9-F4EA-45C8-834A-FB39B26F4B63%40Radio1190.org.
For more options, visit https://groups.google.com/d/optout.