Thủ thuật Log-In, Phân quyền dùng VBA

Liên hệ QC
TuanVNUNI đã viết:
Ngày trước em cũng nghĩ làm theo cách của bác nhưng em nghĩ các chức năng sẽ có rất nhiều (>255), nếu bố trí theo cột sẽ mất nhiều,

Nhiều hơn mình tưởng tượng. nhưng mình nghĩ cũng sẽ có cách. Sơ bộ thì ý tưởng thế này:

1. level như cũ và gồm tối đa 5 level bình quân cho 4 bộ phận = 20. Thí dụ Bộ phận Kế toán gồm các level: KT trưởng, phó, KT tổng hợp,(nhiều khi 3 level này là 1), 5 NormalUser 1, 2, 3, 4, 5. Các Normal User khác nhau ở phân công chứ không khác ở chức vụ. Sale ít hơn, Tiếp thị còn ít hơn nữa.
2. Mỗi level gồm tối đa 10 chức năng con thí dụ Kế toán tiền mặt: Form thu chi, báo cáo Quỹ, báo cáo nhanh, sổ cái tiền mặt, Report phiếu thu chi, In Phiếu thu chi. Cái này mình gom lại trên 1 form của Kế toán thu chi. nghĩa là khi level là NormalUserCash, thì chỉ mở được 1 form, từ form đó làm được đủ các việc cần thiết của Cash như mở form con nhập liệu, lập báo cáo, in báo cáo.
Tương tự KT kho, level là NormalUserInventory chỉ mở được 1 form kho, trên form đó sẽ có đủ nhập liệu nhập kho xuất kho, in phiếu nhập xuất, báo cáo tồn kho chi tiết và tổng hợp.
KT kho không mở được form của KT tiền mặt thì đương nhiên sẽ không mở được các thứ khác nằm trong form đó.
Mỗi nhân viên đực mở form nào, KTTH được phép mở mấy form, Kế toán phó được phép mở mấy form, xác định bởi các AccFunc1, 2, 3 . . .

3. Các bộ phận khác cũng tương tự như vậy.

Tóm lại là do cơ cấu tổ chức chung, phối hợp giữa cấu trúc Database, cấu trúc tổ chức form, cấu trúc tổ chức Report.

Khi nào bác làm file demo xong thì gửi lên dây anh em cùng học hỏi thêm
Chắc mình không dám làm nhiều hơn vì chưa làm bao giờ. Chỉ có file của bài 19, nhưng sợ các cao thủ cười cho. Vì

Ngày trước em cũng nghĩ làm theo cách của bác
Bạn đã nghĩ thì cũng đã biết làm, mình chen vào đây lại là múa rìu qua mắt thợ nữa. Hìii, thôi cũng không sợ xấu, đưa lên luôn.
 

File đính kèm

  • PhanQuyen.rar
    20.8 KB · Đọc: 580
Lần chỉnh sửa cuối:
To:ptm0412,

Mình làm như thế này các bạn có thấy ổn không?
_ TbRight của mình chỉ có một trường chứa các chuổi phân quyền cho các chức năng. Ví dụ: fnUpdate, fnDelete, fnEdit,...
Như vậy sRight = "fnUpdate, fnDelete, fnEdit,..."
Chuỗi này được mã hóa và đưa vào bảng dữ liệu.
Mỗi khi mình kiểm tra sẽ được giải mã và kiểm tra. Nếu với từng người dùng chuỗi đại diện cho chức năng mà tồn tại trong sRight thì coi như là người này được thực hiện thao tác này.
_ Tương tự như vậy: mình cũng có trường để phân quyền đến từng form.
(Đối với việc này mình muốn đưa ra một trường khác cho dễ đó mà)

Lê Văn Duyệt
 
Gửi anh ptm0412
Theo cách của anh em thấy không ổn.
+ Table "GroupTb", ngoài cho biết tên thì không thể hiện tác dụng gì?
+ Table "RightTb" thể hiện sự phân quyền theo từng nhân viên và các chức năng theo cột. Có ba điểm không ổn:
1- Với những nhân viên có chung một quyền thì ta vẫn phải tạo quyền cho từng người một mà lẽ ra chỉ cần phân quyền cho một nhóm là xong, dù trong nhóm có hàng trăm người;
2- Các chức năng thể hiện theo cột, khó mà thể hiện được một cái tên rõ ràng Func1, Func2,...ta không biết nó làm những cái gì (vì không có ghi chú), tên cột chỉ là để ghi mã ngắn gọn, nếu muốn ghi rõ thì độ dài chuỗi chỉ tối đa là 64 ký tự nhưng khi lập trình sẽ rất khó khăn. Các chức năng trong một ứng dụng có hàng trăm nếu chỉ có tên Func1, Func2 chắc chắn chính người lập trình cũng không thể nhớ nổi, điều nữa là không chỉ định được các chức năng thuộc module nào? Khi lập trình, các chức năng thường phải chia theo module: Nhân sự, Tiền lương, Bán hàng, Kế toán,....Điều nữa anh sẽ thiết kế form phân quyền cho người dùng như thế nào?
3- Lập trình rất khó khăn. Giả sử có 100 chức năng thì trong lập trình, để gán chức năng vào CSDL anh phải làm như thế này:
Rs.Fields("Func1").Value=True
Rs.Fields("Func2").Value=False
...
Rs.Fields("Func100").Value=False

Những phân tích ở trên là do ngày trước em đã làm một PM bán hàng và đã thiết kế phần phân quyền như anh đã làm và về sau phải làm lại toàn bộ phần phân quyền. Nếu với mô hình anh đưa ra mà thành công thì cũng rất đáng để học hỏi đó. Nếu có thể anh có thể làm demo được không?

levanduyet đã viết:
Mình làm như thế này các bạn có thấy ổn không?
_ TbRight của mình chỉ có một trường chứa các chuổi phân quyền cho các chức năng. Ví dụ: fnUpdate, fnDelete, fnEdit,...
Như vậy sRight = "fnUpdate, fnDelete, fnEdit,..."
Chuỗi này được mã hóa và đưa vào bảng dữ liệu.
Mỗi khi mình kiểm tra sẽ được giải mã và kiểm tra. Nếu với từng người dùng chuỗi đại diện cho chức năng mà tồn tại trong sRight thì coi như là người này được thực hiện thao tác này.
_ Tương tự như vậy: mình cũng có trường để phân quyền đến từng form.
(Đối với việc này mình muốn đưa ra một trường khác cho dễ đó mà)

Có thể em chưa hiểu hết ý đồ của anh nhưng em vẫn thấy không ổn?
TbRight chỉ có một cột là tự mình làm khó chính mình rồi, anh sẽ phải diễn tả sự phân quyền theo chuỗi, trong chuỗi đó còn phải thể hiện quyền cho từng User nữa...Anh phải viết một loạt các hàm để nhận biết các đoạn phân quền mà không dễ dàng gì.

Môt hình phân quyền mà bài trước em đưa ra là đã thiết kế thành công với các ứng dụng em đã làm.

Tạo Group và User:
User.jpg


Phân quyền:
Rights.jpg
 
Hic, mình chưa làm vụ này lần nào, cái mình đưa ra chỉ là 1 ý tưởng. Cụ thể là thế này:

1.- Khi mở PM lên sẽ là 1 form khởi động, tạm gọi là Main.
- Từ form Main này sẽ có những commandButton gọi ra những form chức năng con cấp 1 tạm gọi là Sub1st.
- Nếu group là Accounting thì cmdAccBtton.Enable = True, các button khác sẽ có Enable = False, tạm hiểu là nhân viên Kế toán chỉ vào đựợc Sub1stAccForm mà không vào được Sub1stSaleForm.

2. Đối với từng bộ phận: thí dụ bộ phận KT:
- Trên Sub1stAccForm sẽ có những CmdButton để mở những form con cấp 2 tạm gọi là Sub2nd.
- Nếu Level = NormalUserCash, ta sẽ cho cmdCashButton.Enable = True, các CmdButton khác có Enable= False, nghĩa là nhân viên KT tiền mặt chỉ vào được Sub2ndCashForm có phần hành của mình mà không vào được Sub2ndInventoryForm của phần hành kho hoặc các phần hành khác.
- Các nhân viên KT tổng hợp có level = General sẽ có thể mở nhiều Form liên quan đến phần vịệc của mình, thì với Level của nhân viên đó, sẽ được Enable = True cho 2, 3 hoặc 4 CmdButton theo phân công.
- Trưởng phòng KT đượng nhiên được quyền vào tất cả các Sub2ndForm của bộ phận KT có trong Sub1stAccForm , mọi Command button đều có Enable = True

3. Trên các Sub2ndForm sẽ có các CmdButton chức năng nữa như: nhập liệu, sửa chữa dữ liệu, xem báo cáo loại A, báo cáo loại B. . . , in báo cáo X, báo cáo Y của Kho này, công trình kia.
- Chính các AccFunction quy định cho biết trong 3 NormalUser cùng level, ai vào phần nào, ai được vào cả 3 phần, ai được in phiếu thu chi, ai được in sổ quỹ. . . tất cả là gán giá trị cho Property Enable = true hay False

4. Các AccFunction và SaleFUnction là tuỳ biến cho các bộ phận do cơ cấu tổ chức của các bộ phận là khác nhau: Thí dụ bộ phận Sale phân công nhân viên theo khu vực thị trường, mỗi nhân viên phụ trách thí dụ 1 vùng miền thì có quyền truy cập dữ liệu trong khu vực do mình phụ trách. Nếu dữ liệu là chung cho cả phòng KD, thì căn cứ vào SaleFunction, dùng Query lọc dữ liệu theo vùng thị trường đó, hoặc lọc theo UserID nếu đặt trường USerID vào table dữ liệu chung. Như vậy không động chạm đến dữ liệu của người khác.

Anh Duyet đã viết:
_ TbRight của mình chỉ có một trường chứa các chuổi phân quyền cho các chức năng. Ví dụ: fnUpdate, fnDelete, fnEdit,...
Như vậy sRight = "fnUpdate, fnDelete, fnEdit,..."
Chuỗi này được mã hóa và đưa vào bảng dữ liệu.
Mỗi khi mình kiểm tra sẽ được giải mã và kiểm tra. Nếu với từng người dùng chuỗi đại diện cho chức năng mà tồn tại trong sRight thì coi như là người này được thực hiện thao tác này.
Mình thấy chuỗi phân quyền gồm nhiều chức năng mà lại nằm trong 1 field sẽ khó:
- Khi tạo User mới hoặc phân công lại nhân sự, việc gõ lại chuỗi phân quyền đòi hỏi chính xác cao, không được gõ sai dù 1 ký tự
- Khi tìm các chức năng của 1 User phải phân tích chuỗi để tách ra 3 hoặc 4 chuỗi con, mỗi chuỗi con mới là căn cứ để xác định quyền. Tách chuỗi không phải là khó, mà là khổ, tự làm khổ mình.

Vài ý tưởng thô thiển không biết có thích hợp không, vì mình chỉ mới chèo trong ao cạn nên chưa lường hết mọi vấn đề ngoài biển lớn.
 
Lần chỉnh sửa cuối:
Bổ sung:
Nếu phần mềm không dùng Startup Form mà dùng menu, thì cũng đơn giản là hiện menu này, không hiện menu kia, Enable dòng menu này, Disable dòng Menu kia.
Còn các trường Group, Level, SubFunction chẳng qua là biện pháp chia để trị: 200 = 4 x 5 x 10
Không biết có đúng hoặc có phù hợp không nữa.
 
Lần chỉnh sửa cuối:
To: TuanVNUNI,

TuanVNUNI đã viết:
TbRight chỉ có một cột là tự mình làm khó chính mình rồi
Em hiểu sai ý anh rồi. Dĩ nhiên trong bảng này còn có UserID.

TuanVNUNI đã viết:
Anh phải viết một loạt các hàm để nhận biết các đoạn phân quền mà không dễ dàng gì
Chỉ cần dùng hàm tìm chuổi này trong chuổi kia thôi mà!
ptm0412 đã viết:
- Khi tạo User mới hoặc phân công lại nhân sự, việc gõ lại chuỗi phân quyền đòi hỏi chính xác cao, không được gõ sai dù 1 ký tự
Ai lại đi làm thế. Khi phân quyền, cũng tương tự như TuanVNUNI, chọn CheckBox => Xây dựng chuổi phân quyền mà!

Lê Văn Duyệt
 
Sorry anh Duyệt. Mình chưa thấy được toàn cục, do chỉ đọc được 1 đoạn ngắn quá không suy rộng được thêm. Ừ phải, ai lại đi làm thế, tại mình hiểu sai thôi.
Phải đọc kỹ lại từ đầu topic thôi.
 
TuanVNUNI đã viết:
Việc phân quyền là phân cho nhóm chứ không phân cho User, khi phân cho nhóm "Bán hàng" thực hiện {"Cáo cáo 1"; "Báo cáo 2"} thì tất cả các thành viên trong nhóm này có quyền như nhau.
Vậy tuân cho anh hỏi, như vậy sẽ không linh động. Vậy nếu chúng ta muốn phân quyền kết hợp giữa Group và User thì ta nên thiết kế lại mô hình quan hệ giữa các tables như thế nào?

Xin các bạn khác, đã từng có kinh nghiệm về cái vụ này cho ý kiến.

LTN
 
lethanhnhan đã viết:
Vậy tuân cho anh hỏi, như vậy sẽ không linh động. Vậy nếu chúng ta muốn phân quyền kết hợp giữa Group và User thì ta nên thiết kế lại mô hình quan hệ giữa các tables như thế nào?

Xin các bạn khác, đã từng có kinh nghiệm về cái vụ này cho ý kiến.

LTN

Ý anh là những người trong một Group lại có người có quyền cao hơn hoặc thấp hơn?
Trong tblUser em đã thiết kế một trường Level, trường này có giá trị 1,2,3,...Trong tblFunction, thiết kế thêm một trường Level để gán giá trị 1,2,..tuỳ vào tính quản trị của mỗi chức năng. Như vậy ta co một cơ sở quan hệ ràng buộc giữa các table
(tblUser.GroupID= tblGroup.GroupID And tblUser.Level=tblFunction.Level)
Theo cách thiết kế trên, anh hoàn toàn có thể làm được tất cả.
 
TuanVNUNI đã viết:
Ý anh là những người trong một Group lại có người có quyền cao hơn hoặc thấp hơn?
Vì theo anh thấy trong SAP phân quyền cho mỗi chức năng.
Ví dụ:
_ Anh vẫn có thể vào các chức năng, nhưng trước khi thực hiện hệ thống sẽ kiểm tra việc phân quyền. Em xem hình sau:
Mỗi chức năng để thực hiện người ta sẽ dùng T-Code (giống như shortcut vậy)
SAP.jpg


Lê Văn Duyệt
 
Theo mô hình của em cũng là phân cho từng chức năng đấy.

(*) Khi phân quyền cho một nhóm (Group) sẽ thực hiện như sau:
+ Load tất cả các chức năng từ tblFunction ra form giao diện người dùng (UI)
Các chức năng được liệt kê chi tiết: Phiếu Thu: Tạo; Sửa;Xoá, Phieu Chi:.....
+ Thực hiện việc tick chọn các chức năng cho phép chạy với nhóm
+ Lưu toàn bộ chức năng được tick chọn vào một table có tên tblRight

(*) Khi người dùng thực hiên "Đăng nhập", hệ thống sẽ thực hiện:
+ Lấy toàn bộ thông tin từ các table có quan hệ của UserID đã đăng nhập thành công. Các thông tin được lưu trong một Query/View có tên qryUserRight - Kết quả của một truy vấn móc nối giữa các table có quan về Group,User,Right,Function.
+ Khi người dùng thực hiện một chức năng, chương trình sẽ tìm mã chức năng đó trong trong table qryUserRight, kiểm tra xem có và được tick không?
 
- Sau khi gán 1 User vào 1 Group thì ban đầu các User đó đều có quyền của Group đó.
- Tuy nhiên, sau khi assign vào Group rồi thì vẫn có thể thay đổi lại quyền của User đó (hạn chế bớt đi)

Anh Duyệt sướng thật đấy, được làm việc với SAP.
 
Xin chào các anh. Các Anh cho em hỏi với, để giới hạn thời gian sử dụng (hoặc số lần chạy) của chương trình (sau khi đã cho username và password) thì tạo code như thế nào ạ ?
 
hix, đọc xong mà vẫn không hiểu gì cả.Sao excel lại dính đến access vậy? Không biết có bài viết nào hường dẫn 1 cách cơ bản mối liên kết database giữa access và excel và cách truy xuất qua lại là như thế nào không?
Anh em nào có xin vui lòng share link nhé.
Xin chân thành cám ơn.
 
Vấn đề là bạn phải biết thông báo lỗi gì?
Tôi chắc chắn đó là việc bạn phải reference đến các *.ocx.

Lê Văn Duyệt
thật sự là khi nhìn vào form từ notepad mới thấy được bác duyệt không đưa mọi người hàm convert VNI to Unicode, được dùng trong msgbox
File của bác mình mở mãi mà không được, import cứ báo lỗi.
Bác có thể cho mọi người luôn bằng xls được kô ạh, import chắc kô mất đến 1p của bác đâu nhỉ.
Thanks bác nhá
 
thật sự là khi nhìn vào form từ notepad mới thấy được bác duyệt không đưa mọi người hàm convert VNI to Unicode, được dùng trong msgbox
File của bác mình mở mãi mà không được, import cứ báo lỗi.
Cái này đã có trên diễn đàn. Bạn vui lòng tìm kiếm bài của A.Tuân.

Lê Văn Duyệt
 
Vba

Thật phức tạp! sao các ông khong phân quyền người dùng theo kiểu mã khoá đi
Hoạc thiết kế 1 trang Web sau do cho người dùng đăng ký qua trang Web đó.
có rất nhiều cách hay hơn nữa.
 
Thật phức tạp! sao các ông khong phân quyền người dùng theo kiểu mã khoá đi
Hoạc thiết kế 1 trang Web sau do cho người dùng đăng ký qua trang Web đó.
có rất nhiều cách hay hơn nữa.

ông nói gì ông hiểu không vậy
ông biết người ta đang nói tới vấn đề gì không?
 
Xin chào các anh. Các Anh cho em hỏi với, để giới hạn thời gian sử dụng (hoặc số lần chạy) của chương trình (sau khi đã cho username và password) thì tạo code như thế nào ạ ?
Lúc đăng nhập , kiểm tra user & pass , đúng ghi nhận số lần đăng nhập n (n=n+1); thời gian = start time = giờ trên win (hoặc tự tạo bộ đếm)
Lúc thoát chỉ ghi nhân end time, spend time = end time-star time ; s=s+s'
check n, if true then exit
check s, if true then exit
 
Web KT
Back
Top Bottom