Most of our staff work remotely in different countries of the world.
Often several staff work (on different aspects) of the same case.
At the moment the person who initiates the cases has to email the office manager who has to inssue a case number which then has to be shared with different staff members to make sure they use the same Case number in their forms and correspondence.
I was wondering whether it would be possible to:
Have a page on our website (accesible to our staff only)
Where the person initating a case goes to
The staff member is asked to enter his initials (eg DH or RD)
Then automatically a code is generated (RD001, DH001, etc.), it will be helpful for other purposes if the number is always 5 characters long (e.g. RD001, RD025, RD234, etc...).
These numbers need to be sequential (so if RD got the number RD001 1 hr ago, or 1 day ago, he needs to get RD002 the next time he requests a number), so the page needs to remember the last number that was issued for that staff member (they need to be sequential per staff member).
That number is then emailed to the relevant staff members who need to be aware that this number has been issued
Is that possible?
Sure it's possible, but what you are asking is actually a complete solution development. You've to hire a developer, who will create a system with authentication AND authorization, cases management (new case, details of the case, etc...) and so on.
But overall, it's a trivial job : )
EDIT: If your question is exclusively considering only HTML, then I really don't think this is possible, since your "number" should be generated and accessed from anywhere. Then, you have to make it globally accessible.
Also, it's really important that only your staff, and only the ones with rights to do that, could access and/or generate new numbers, hence the authorization/authentication need.
EDIT 2: Another possibility is search for a already made solution. I believe that should exist even online services with your requirements, like some online CRM or something like that.
I have a couple of business-related domains like Purchase, Marketing and Economy. Having the models arranged into a namespace* for each domain would be nice, but there are some entities cutting across domains, like an Item. How to organize those cross-cutting objects?
* = As in C#/Java/Python namespaces.
Since you have the concept of Bounded Context, you should not share domains between the namespaces. Actually, you should have one Item for each namespace that requires it, and each of those Item should have it's own fields as required by the context it is included.
As Eric Evans said, it is not a big deal replicate data in order to never share the same domain between contexts, but only data.
Determining whether you have the correct design will require some experience with the domain so you should check with your domain expert.
You may very well require a Shared Kernel for classes that are cross-cutting. You'll have to be careful that you do not abuse the shared kernel by placing too many generic / logical classes in there.
To add to what #rafaels88 has answered you may need to create a BC specific domain construct where some logical entity exists. For instance, a User in the Identity & Access Control BC would be an Author in one BC but perhaps a Supervisor in another.
You could also duplicate an AR in one BC as a VO in another. A Customer in the CRM BC may be the system of record for a customer and, therefore, contain a whole lot more information. In the Order BC, however, a Customer VO may only contain an Id, Name, and perhaps Address (for example).
So you will need to evaluate what type of object you have before deciding where to place it.
I'm developing a website and need to create an ERD for the website. I've never created one before but will be using MySQL to design it once I figure out the tables necessary. All I am asking for is for ideas on what tables might be necessary for this website. Here is a link to an image of the website:
!
Obviously there needs to be a user table. I have that created already with all pertinent info. Do I need to create a login, register, home, elite login, photos, events, newsletter, and contact us tables? The photo link will bring the user to a page where there are folders for each event, if you click on the folder it then opens up another page with the actual photos, but you need to be a registered user to view these. Is the login hyperlink going to be the user table? Would the register link be to another table or would that add to the user table? The events page is only going to be a list of hyperlinks that take you to a new page with dates and descriptions of the events, does this need it's own table? And lastly does the newsletter and contact us pages need separate tables as well?
Like I stated, I am not looking for anyone to help create the dERD but only to let me know if all these tables would be necessary. From there I can build the ERD and create the appropriate relationships and so forth.
You would probably benefit from learning about MVC- Model, View, Controller systems.
Views (in a webapp) map pretty well to the HTML pages you display.
Models map pretty well to the "Nouns" in your system- these are the things in your database; Users, Photos, Newsletters are examples of things that go here.
Controllers map to the "Verbs" in your system- Register, Subscribe, Upload, Save, Login are all actions that a controller might provide.
Only the Model layer lives in the database in most frameworks.
I'd suggest that you think about your problem in a more holistic fashion, rather than diving into diagramming a bunch of unrelated ideas. ERD's really only map to the stuff you need to be persistent.
I would recommend that you first draw paper prototypes of most of the user interfaces, at least at a high level. Then do usability tests on those prototypes to make sure your interface designs make sense to someone other than you. (User Interface Design by Soren Lausen is a good book for that.)
Then, once you have a decent idea of how your interfaces are going to work, think of the models necessary to make those interfaces work. Obviously, a login form with a username and password will require a User entity with username and password (or, actually, encrypted_password) attributes. Getting all these models nailed down may take some skill that I sense you may not have yet, but this task will be much easier and clearer to you if you have your interfaces drawn out than if you're just trying to sit there and think about it. Your first pass will probably be wrong, but that's okay. Start with the smallest subset of the program that could be useful on its own, build that to the point where it's completely working, and then expand from there.
Good luck!
After looking this over I have come to realize that I have jumped the gun quite a bit and need to do a lot more work on the design of the site before even thinking about the ERD. The client has only approved the mock up of the "home" page and the other pages have yet to be discussed at any length. Nothing is set in stone as it were. Therefor, creating an ERD is very premature. Many thing, from now until the database needs to be looked at, can change.
Please excuse this topic as I was overly excited about my first project. I need to focus on the agile development process and slow down. Focus on the individual steps and let things develop from that.
I have been looking through examples of email activation on rails and most examples just have a column for activation token and confirmed in their user table. I am not sure but I don't think that this is a good idea as when a user is activated almost both those columns seems like a waste. The way I was thinking of doing activation was having a seperate model called Activation which would have_one :user a ONE-WAY association and I would set the role of the user in my site as "PENDING" or something similar. The activation table would hold an activation token(s) per user. Then a link would be generated with the activation token(s) and the user would be sent an email containing something like www.mysite.com/activate?token='some_really_long_hash'. Upon clicking the link the role of my user would be set to "MEMBER" or something similar. Does this seem like a good idea? I can't conceive any pitfalls of activation this way. Suggestions? Comments?
It sounds like you're at the intro stages of implementing a state machine design pattern on your user model, and no it isn't a bad approach to design. Its just more complicated than what most people need.
I think the State Machine Plugin might be the type of approach you're looking to perform. Obviously this might be more than you're looking for but the approach would be the same.
Also check out these posts:
Why developers should be force-fed state machines
why-developers-never-use-state-machines
Good Luck!
The most straight-forward approach is to generate a random token and save it into a column of the user or member record. It doesn't have to be "really long", 20 random characters will suffice as the probability of guessing that is so slim it will never happen.
Typically the token is used once and once only to validate the user, but if the user clicks on the email a subsequent time it's nice if it still redirects back to their profile.
Usually the user is switched to "validated" or something of the sort, a status flag stored in a separate column. This preserves their initial membership type which might be one of many values. This is why you often see validated_at fields or banned_until fields.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm back and forth on the idea of letting the users on my site change their usernames, which would be displayed through out the site. On one side I want to give the users flexibility. But on the other, I don't want them to use this feature as a way to hide if they do something unwanted on the site. I know SO & Twitter lets you change your display name. Whats keeping someone from behaving bad on the site and then changing their name so they can continue behaving bad?
I need feed back on the pro's and con's.
Thanks!
Update:
To clear things up a bit. I'm not using the user name as the primary internal account ID.
Each user gets a unique number. My question is not really about my system tracking the user its about how other users will be able to track each other.
If userA knows that userB is doing something bad and then userB changes his name to userC. Then userA will no longer know who he is.
What do you mean with "do something bad and then change their name"? If you're implying that users can post content, for instance, with their name attached, and then change their name and the name attached to their posts won't change as well, then I think you need to reconsider your (database) architecture and ensure that a username is a single point of reference and all representations of that username change when someone changes their username.
Edit:
OK, sorry for misunderstanding. But if it's the case that you have a single point of reference, then changing your username is irrelevant to the problem. Let's say my username is Foo and I troll some thread somewhere, then change my name to Bar. As long as people can see what I've posted (eg. a post history page), then it doesn't matter whether I used to be called Foo or not, Bar is associated now with posts made before that were troll material. So perhaps you just need to create transparency, by making something like a post history overview on users' profiles? :)
If the issue of impersonating someone or "cheating" is a factor you could always do ALA eBay and display an icon next to someone who changed their username in the past 30 days.
Depending on the case you can keep an history and display it if required.
If you do that make sure that previous usernames are not recycled for new users.
There are often very good reasons why people would want to legitimately change their username.
For example, assumed someone signed up as pimpleOnGodsAss while at university and then, a few years later, is in the workforce and wants to network with other professionals through the site ... they're going to want to change!
Also, consider the very common case of people changing their names when they marry - if they used their family name as a part of their username, they'll want to change that too. Martha Jones with username marthajones marries John Smith and wants username marthasmith (if available).
Note too that you can't avoid people achieving this - they can always reregister with a new email address, discarding their old history, and getting the new username they want.
I'd suggest that the benefits of the feature outweigh the costs - people will always find a way to game the system, don't penalise good users by locking away features just because some will find a way to abuse them.
I like Steam's "View aliases" function, which lets you see all names that you've seen that user using. As long as the username itself isn't the primary key in the user table, then sure, let them change names. Add an alias table so if someone's being a dick, you can see who they used to be.
You could display both names for a while :
Symbol Guy -> Formerly known as Prince
I wouldn't let the user change their actual username.
However, changing the display name should be safe. You can always track their behavior via their account or username directly. If they're doing something bad, you should flag their account, not necessarily try to track it by their name.
Most sites have this concept (including SO).
If each user has a constant unique id number, they can change the username but are still the same.
Arstechnica.com charges $20 to change your username, and subscribers get one change for free.
It's a feature I'd like to see on more websites.
It's convenient and, as you said it, gives user flexibility. If only changing one's username is enough to hide, there may be another issue.
Keep track of those users another way (user ID, logs, reputation system, ...) and consider showing the original username to your admins/moderators maybe.
I agree with most of the people answering here - let the users change their name, otherwise the site is simply less friendly. As Rahul said, if a user changes their name, make sure that the new name is associated with all their prior activity.
Similarly - If you use email address as your username (as many sites do), let the user change their email address. I can tell from personal experience that not allowing this is a real pain (for users and customer support for whatever site isn't allowing it).
Your database structure shouldn't depend on the username(/email address) being the same, so why enforce that on your users?
If you have the feature, leave it. You would just be encouraging someone to create another account to have the user names goodwitch and badwitch.
If you don't have it, don't add it unless you have nothing better to add.
Personally, i try to make usernames sticky, and a valuable part of the experience of a site.
This is true if other users will see the user names; if there is any social networking involved with the site.
You can always archive really old ones if your site lives for a long time.
As a user, I must say that I absolutely want to be able to change the user name on my account. I wouldn't go as far as asking for multiple aliases, but it is always possible that someone changed his mind, or did not really think much when first setting up the account.
You should not be using the user name as the primary internal account ID.
Yes - ONLY IF users don't interact with another users.
NO - if users can interact: forums and stuff like that. It's kinda confusing to see an user with a different name every day.
I'd allow the change, and perhaps carry both a user (login) name and a display name, and I'd allow a change to both. There are various arguments on both sides, but for me it usually comes down to the fact that either/both of those elements (user & display) typically reflect something about their owner's name, and their owner's name can change.
If your login is an email address, and you change email providers, now what? Or take your name 'Donny V.' I assume you're male, but what if you were female*? And if you got married to Mike Peterson. Wouldn't you now want to be known as "Donny P."? Maybe, maybe not. But many would.
*Yes, I know men can change their last names too.
How about a "formerly known as" display. If a user decides to change the user name, just store the old name in a table and display it additionally. Maybe give the option in all the user profiles to disable this display.
I vote for yes, within reason. Users who have got into trouble (negative total rep, moderation, past warnings, whatever is applicable to your site) should not be allowed.
Other users should be allowed but with a limit (e.g. 3 times a year). There should be a way to keep track of the users past usernames, at the very least for the admins/moderators.
EDIT: However I find systems such as Steam/Wordpress where a user has a display name and login name seperate a little confusing, so I would not reccomend such an approach, however that is just personal feeling.
If userA knows that userB is doing something bad and then userB changes his name to userC. Then userA will no longer know who he is.
If you're main concern is related to abuse, perhaps you should provide a method of reporting abuse, and maintain a log of when usernames change.
You could always control how often users are allowed to change their username to avoid seeing same people in forums who change their name every day; cause someone will do it every day if they are allowed to.
Business questions first
Why are you offering this feature instead of spending the time on another feature? Would another feature offer better benefit (such as a status line?)
What will this accomplish?
Are users asking for this?
Will this feature result increased stickiness or better experience?
Is this a competitive advantage?
Does your site become more confusing?
Technical questions
What is the potential for misuse? Do you have a denormalized database where the username has been copied many places or is there only one place where the username is stored?
Do you have a way to stream a notification to other users "Your friend 'foo' is now 'bar'?"
Like most things in life, it comes down to the context of which you speak of. Personally, I find any service that could or gets abused should have persistent usernames.
Suppose it is ok to let user change their names, but this change should also touch his previous posts - they should be shown with new user name
...
I have reminded about some password has realization that I found in internet resource
password_hash = md5(password + salt + user_name)
if you have the same model then you should reject chaning user name
Regards, Pavel
Combining some of the ideas here:
Every user has a unique internal ID, a number. So you are free to implement this feature any time you want. No need to code it right away, as you can delay this decision.
In case you want to implement it: Let them only change the username every 6 months and indicate every new username by some symbol for 30 days. Show the username history in the profile and be sure to inform the user about this, so he can decide against changing the username.