benlau / gogogohk

Automatically exported from code.google.com/p/gogogohk
0 stars 0 forks source link

"Delete" entry in edit page #23

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Just like Django admin interface , the edit interface should also have a
button of "Delete" which could delete the entry.

Original issue reported on code.google.com by xben...@gmail.com on 24 Aug 2009 at 3:52

GoogleCodeExporter commented 9 years ago
may edit following files to add "Delete" button.
- gogogo/templates/gogogo/transit/agency.html
- gogogo/templates/gogogo/transit/route.html
- gogogo/templates/gogogo/transit/stop.html
- gogogo/templates/gogogo/transit/trip.html

and, add url conf + py handlers for delete.

BUT, are we going to carry lazy delete instead of issuing a delete to db? may 
this
harm to backup / restore ?

Original comment by mr.ksc...@gmail.com on 27 Aug 2009 at 6:38

GoogleCodeExporter commented 9 years ago
Sorry that I didn't wrote it clearly. The edit interface is located in the URL 
of
/db/agency|route|stop|trip/edit , it is not going to show the "Delete" button in
transit pages.

For your concern, I think we may limit the delete right to admin only. Staff 
user can
only issue a report of removal request. What do you think?

Original comment by xben...@gmail.com on 27 Aug 2009 at 8:33

GoogleCodeExporter commented 9 years ago
The current implementation does not allow staff to edit...

and, the template should be gogogo/templates/gogogo/db/edit.html

Original comment by mr.ksc...@gmail.com on 28 Aug 2009 at 10:43

GoogleCodeExporter commented 9 years ago
I mean the links/URL in web server. They are all linked with 
gogogo.views.db.forms.edit

Moreover, the current implementation could only allow staff user to edit. 

Original comment by xben...@gmail.com on 28 Aug 2009 at 12:00

GoogleCodeExporter commented 9 years ago
how do that being differentiated? The login page have only "Sign in as 
Administrator"
as option. I used the default "test@example.com" for my trial.

Original comment by mr.ksc...@gmail.com on 28 Aug 2009 at 12:53

GoogleCodeExporter commented 9 years ago
The development server allow you to use any login name to login the system , 
then it
will create a record about the user in the database. Visit the admin interface,
inside the Auth >> User page , you may set the "Staff" and "Superuser" status 
for any
user.

Original comment by xben...@gmail.com on 28 Aug 2009 at 1:00

GoogleCodeExporter commented 9 years ago
ok... so delete can only be done by django "superuser" but not django "staff"

Original comment by mr.ksc...@gmail.com on 28 Aug 2009 at 1:04

GoogleCodeExporter commented 9 years ago
tasks....
- modify template edit.html
- add generic url for delete
- add python handler
  * should check user's identity as superuser.

Original comment by mr.ksc...@gmail.com on 28 Aug 2009 at 1:19

GoogleCodeExporter commented 9 years ago
app-engine-patch does not distinguish django-staff and django-superuser....

Under development server...
once checked "log in as administrator" ... user gains superuser right.
if not checked "log in as administrator" ... user even does not gain staff 
right.

Under deployment server...
once login with a django-staff gmail account, the account automatically granted 
as
superuser....

decorator "staff_only" from app-engine-patch may already solve privilege 
checking.

Original comment by mr.ksc...@gmail.com on 2 Sep 2009 at 8:10

GoogleCodeExporter commented 9 years ago
ks,

The creation of superuser account will also set the is_staff flag. It can be 
changed
in admin interface (within user database). But account with only is_staff won't 
have
superuser right. I think they are different. (p.s the django staff gmail 
mean..?)

Original comment by xben...@gmail.com on 2 Sep 2009 at 9:21

GoogleCodeExporter commented 9 years ago
Hey,

As our decision is only admin can delete entry , then it may just use the admin
interface for the job (with modification that it will leave the record in 
changelog).
We don't need to implement a new web page.

Original comment by xben...@gmail.com on 2 Sep 2009 at 9:31

GoogleCodeExporter commented 9 years ago
The experiment is like this. I deployed a version to the deprecated staging 
server.

i created a user with a gmail account through django-admin with following 
properties
- is_active
- is_staff

i login that user via the login page... and then just logout.

and, login again with another "superuser" account ...

once checked the User list inside django-admin ... that "staff" user account has
granted is_superuser.

Original comment by mr.ksc...@gmail.com on 2 Sep 2009 at 9:52

GoogleCodeExporter commented 9 years ago

Original comment by mr.ksc...@gmail.com on 5 Sep 2009 at 12:22