Closed GoogleCodeExporter closed 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
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
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
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
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
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
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
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
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
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
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
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
Original comment by mr.ksc...@gmail.com
on 5 Sep 2009 at 12:22
Original issue reported on code.google.com by
xben...@gmail.com
on 24 Aug 2009 at 3:52