I have users table in my database lay out like this :
id
username
firstname
lastname
email
photo
As of now, since I am an Admin user so I have Admin right, and I can Create, Update, and Delete.
I want to allow all my users to have the same right as me later on.
Before I release this feature, I want to keep track on who edit what - so things doesn't get lost, and it's good to keep the history of things.
What is best practice for this feature ?
I know that I have do some programming logic in my update function in my Controller function.
I know that I have to create a logs table on my database to store
user_id : who make a change
created_at : when the change was made
old_data: string
new_data: string
For someone, that had any experiences with this feature, can you PLEASE give me some advice ?
I really appreciate your concern. Thank You.
I think best approach to this problem is each action that a user takes that you want to log should also fire an event.
Event::fire('some.event', array(Auth::user()));
Then you can register listeners for each event and log appropriately.
Event::listen('some.event', function($user)
{
// create new item in logs table here.
});
Related
I tried to look for an answer of this but I have a question about filtering with codeigniter. The code below checks if the administrator is logged in shows every idea(brain) status in the query, which could be public or hidden, otherwise, it only shows the ones with public status.
I want to change this to keep showing the ideas with public status to everyone and only the ideas with hidden status of the person that is logged in.
if($this->ion_auth->is_admin()) {
$brain_status = null;
}
else {
$brain_status = $brain::PUBLIC_STATUS;
}
$brain_collection = $this->em->getRepository('Entities\Brain')
->getListPerPage($brain::BRAIN_PER_PAGE, $page, $brain_status);
I tried using
$this->session->user_id and I don't know how many other syntaxes and I can't get it to work, every idea has a field in the database where the user_id is logged when the idea is created to accomplish this.
Any help is extremely appreciated
to complete this Q/A pair, I'm transforming my comments into an answer:
the requirement:
admin sees all ideas: public and hidden, regular user only sees public ideas
the solution:
create a database column "published", associated to each idea (and consequently user_id). Now you can show in your view all records which match published=1 to everyone and those published=0 only to whom where user_id matches (or admins).
If a user is logged-in (you set a session with their user_id) and if this user_id matches the user_id of the idea then you show it. It has the advantage that you could implement for a user to be able to publish or un-publish their own idea, without admin intervention, only viewable to themselves, unless published by admin.
Fellow collegues
I tried to implement a simple button inside a Joomla article to see which registered users have read an article and which didn't. I failed miserably, since my knowledge about PHP is honestly too low.
It should be possible to have a reading confirmation button on selected articles, so that the superior can check who has already read important information and who has not.
I was thinking of using php for getting the articleid, userid and a read field to construct a table in MySQLi, and depending on whether it is read or not, read will be either true or false.
the table is constructed already, but filling in the right information really leaves me hanging.
Now Problems occuring:
To fill in every user for each article which should've been confirmed automatically is impossible for me. I know that i can get a users username with the command
$user = JFactory::getUser();
but i dont want to get the current user. It should provide an overview of which users have read the article and which didn't.
I'm really lost in code fragments and I'm having trouble understanding what I could benefit from.
I've already used the search function and this topic already came up several times, but still it seemed to me that it hasn't been answered properly yet.
Has anyone done something similar in Joomla before and could give me a hint on how to get this done?
Or does anyone know an extension which could handle the problem?
Any clarifying statements are warmly welcomed!
Greetings
Capo
The best way to handle this is to use ajax, specifically, the com_ajax Joomla component. It's not as hard as you might think, and we have written a step by step guide on how to use the Joomla ajax component here.
Essentially, you will need to create a button, which, when clicked, will send an ajax request to the server and update a table. The table that should be updated should be a custom table, containing the following fields: id, userid, contentid
The id field will be an autoincrement, the userid will be the ID of the user who read the article, and the contentid will be the ID of the article that the user has read.
Once you have the data in the table, you can then display it anyway you like!
I'm developing a web page where students, after registering, can introduce their school schedule, mark test and calculate averages. My problem is:
how do I do for each user to have their own schedule, calendar etc. I could be simple for you but I'm having difficulties solving this.
This is how I want schedules menu to look
all the data introduced for the schedule will show up on the table
You have to look at how a relational database works.
Everything you're trying to do is use a foreign key.
IMHO best way to achieve this is to register user ID+name in $_SESSION then, when he reaches the page, retrieve schedule from where it's stored. Depends also on the schedule/calendar format
I am building a system that will use a commenting based ticket system. I would like to get some opinions around the idea of flagging a user as deleted or removing the record completely.
Ideally I want to keep the system free of old accounts but at the same time by deleting a user the commenting within the ticket system may not make sense.
Has anyone come up with a solution to this type of problem. My ideas so far:
Delete the users account, comments and all other relevant data.
Flag the user as deleted and create a brand new account if they subscribe again.
Flag the user as deleted but if the user was to try to subscribe again update and unflag as deleted instead of adding a new one.
Delete the user account only. Then when fetching comments etc. check for an associated id, if no result found then display the comment with a message "the users account has been deleted".
What do you think?
I would say that the third option is the best choice
My reasoning for this is any tickets stored in the database should be kept for the life of the database, if you attempt to delete a user from the database, you will remove that users reference to any tickets in the database.
(Thats if the database will let you delete it since the user's id will be linked to any tickets he/she may have created)
When that user goes to create a new account in the ticketing system, the tickets that he may have created months ago have dissapeared and may now have been created by null.
I would always use the last solution: delete the user account only and show an "account deleted" message if the poster's account doesn't exist anymore. If you don't allow users to change their username, you can also save the poster's username (beyond his ID) and display it as plain text if the user deleted his/her account, or as a link if the user is still active.
If you're representing the user <-> comment relationship with a FOREIGN KEY, you can't delete the user without deleting the comment or updating the comment's associated user to either NULL or to point to some "deleted user" fake user account (in either case, losing the information about the user who posted the comment).
The ticketing system I wrote basically did number 3. Anything else will ruin any audit trails you need to keep.
If you need to get rid of old stuff one way is to set cleardown of old tickets. Then, when all related tickets for an account are gone, you can remove the account.
It really depends on you use case.
Personally I would never delete stuff like user-accounts from a db completely.
So option 1 is out. (but that's just me)
Option 2 has the problem, that you'll have lots of dangling user-accounts.
Option 3 looks like the best option -cough- audit trail -cough-
Option 4 is asking for trouble, you have a link to another table, but that data has been deleted.
I need to build a registration system which requires the collection of large data (many fields) from the user registering which is then inserted into a couple of tables in a database.
I don't really want to display a very long form to the user for the purposes of better UX.
This system will not run online, it is just a web app to run on the desktop.
I need help, pointers, references, etc on how I can better organize the registration process to make it more user friendly.
This How to encourage a user to fill in long application forms? has been helpful so far
As long as you don't mind requiring your user has Javascript, I would use AJAX. Let's say that you have 50 fields that you can logically combine into 4 different sets - the first may be about the person asking for name, email, etc., while the next set asks for historical information or employment information - like on an application.
Make one form for each set, and then present a new user with the first. When he completes the first page, instead of a "Submit" or "Register" button, use an AJAX call and a "Next" button to get the info and switch to the next page of the form with the next set of fields. You could use the AJAX calls to hold the information in a temp table in your database, and then, once the entire process is complete, you can write it to your member/users table.
You could do like other surveys or checkouts do and add a "title" for each page of the form above the form fields so that as a user moves through registration, they can monitor their own progress.
I'd recommend checking out the Amazon checkout, or really any multi-page survey (you may even be able to set one up yourself on Survey Monkey) to see how a large number of form fields can be broken down logically in a user friendly way.
Hope it helps.
Check out this link: http://www.smashingmagazine.com/2011/05/05/innovative-techniques-to-simplify-signups-and-logins/
It's talking about login- and registration-forms and how to make them more user-friendly. A suggestion which is also included in this article is as follows:
At registration don't ask the user to many questions. Only the basic data like their name for example. Then ask him about more detailed data when the user logs in the first time. This way the registration won't take too long.
Maybe this helps you out :)