Formating input fields with size and width, posted by UlfO on Wed Oct 3 14:22:29 2012
|
Hi,
Why is the color of an inputfield changing when I have changed the size and width?
I have attached a example.
Regards
/UlfO
|
Re: Formating input fields with size and width, posted by Stefan Ritt on Wed Oct 3 14:23:55 2012
|
UlfO wrote: |
Hi,
Why is the color of an inputfield changing when I have changed the size and width?
I have attached a example.
Regards
/UlfO
|
Please post your configuration file (or the relevant section therein) so that I can have a look.
/Stefan |
Re: Formating input fields with size and width, posted by UlfO on Wed Oct 3 14:28:20 2012
|
Stefan Ritt wrote: |
UlfO wrote: |
Hi,
Why is the color of an inputfield changing when I have changed the size and width?
I have attached a example.
Regards
/UlfO
|
Please post your configuration file (or the relevant section therein) so that I can have a look.
/Stefan
|
OK!
Here it comes:
[Deployment-Plan-PRIMA]
Logbook Tabs = 0
Theme = default
Title Image= <img border=0 src="konturlogo_dynamate.png" alt="DynaMate logo">
Use Email From = weblog@dynamate.se
Use Lock = 1
Mode commands = 0
Comment = Deployment plan PRIMA SSG
Attributes = Activity number, Main Activity task, Activity task, Resources, Task Type, Status, Start Time
Options Main Activity task = Activities pre deployment, Install Changes into Prima, Post Go Live activities week after Go Live
Options Task Type = Depl, Pre, Prep Depl, Prep Test, Prod, Test
Options Status = Finished, Not started, Ongoing
Extendable options = Resources, Task Type, Main Activity task
Moptions Resources = BMM, PMM
Format Activity number = ,,,3,3
Type Start Time = Datetime
Type Activity Number = Numeric
Cell Style Status Finished = background-color:green
Cell Style Status Not started = background-color:red
Cell Style Status Ongoing = background-color:yellow
List Menu Commands = New, Last day, Help
Menu commands = List, New, Edit, Delete, Help
List Display = Activity number, Main Activity task, Activity Task, Start time, Resources, Task Type, Status
Page Title = Deployment plan PRIMA SSG - $Subject
List after submit = 1
Reverse sort = 1
Quick filter = Main Activity task, Resources, Task Type, Status
|
Re: Formating input fields with size and width, posted by Stefan Ritt on Wed Oct 3 14:34:58 2012
|
UlfO wrote: |
Stefan Ritt wrote: |
UlfO wrote: |
Hi,
Why is the color of an inputfield changing when I have changed the size and width?
I have attached a example.
Regards
/UlfO
|
Please post your configuration file (or the relevant section therein) so that I can have a look.
/Stefan
|
OK!
Here it comes:
[Deployment-Plan-PRIMA]
Logbook Tabs = 0
Theme = default
Title Image= <img border=0 src="konturlogo_dynamate.png" alt="DynaMate logo">
Use Email From = weblog@dynamate.se
Use Lock = 1
Mode commands = 0
Comment = Deployment plan PRIMA SSG
Attributes = Activity number, Main Activity task, Activity task, Resources, Task Type, Status, Start Time
Options Main Activity task = Activities pre deployment, Install Changes into Prima, Post Go Live activities week after Go Live
Options Task Type = Depl, Pre, Prep Depl, Prep Test, Prod, Test
Options Status = Finished, Not started, Ongoing
Extendable options = Resources, Task Type, Main Activity task
Moptions Resources = BMM, PMM
Format Activity number = ,,,3,3
Type Start Time = Datetime
Type Activity Number = Numeric
Cell Style Status Finished = background-color:green
Cell Style Status Not started = background-color:red
Cell Style Status Ongoing = background-color:yellow
List Menu Commands = New, Last day, Help
Menu commands = List, New, Edit, Delete, Help
List Display = Activity number, Main Activity task, Activity Task, Start time, Resources, Task Type, Status
Page Title = Deployment plan PRIMA SSG - $Subject
List after submit = 1
Reverse sort = 1
Quick filter = Main Activity task, Resources, Task Type, Status
|
Ok, here it is. You wrote
Format Activity number = ,,,3,3
who told you that you can just leave out the first three arguments? The documentation says that you can trailing parameters can be omitted, not leading. So what you want is
Format Activity number = 0,attribname,attribvalue,3,3
/Stefan |
Re: Formating input fields with size and width, posted by UlfO on Wed Oct 3 14:46:44 2012
|
Stefan Ritt wrote: |
UlfO wrote: |
Stefan Ritt wrote: |
UlfO wrote: |
Hi,
Why is the color of an inputfield changing when I have changed the size and width?
I have attached a example.
Regards
/UlfO
|
Please post your configuration file (or the relevant section therein) so that I can have a look.
/Stefan
|
OK!
Here it comes:
[Deployment-Plan-PRIMA]
Logbook Tabs = 0
Theme = default
Title Image= <img border=0 src="konturlogo_dynamate.png" alt="DynaMate logo">
Use Email From = weblog@dynamate.se
Use Lock = 1
Mode commands = 0
Comment = Deployment plan PRIMA SSG
Attributes = Activity number, Main Activity task, Activity task, Resources, Task Type, Status, Start Time
Options Main Activity task = Activities pre deployment, Install Changes into Prima, Post Go Live activities week after Go Live
Options Task Type = Depl, Pre, Prep Depl, Prep Test, Prod, Test
Options Status = Finished, Not started, Ongoing
Extendable options = Resources, Task Type, Main Activity task
Moptions Resources = BMM, PMM
Format Activity number = ,,,3,3
Type Start Time = Datetime
Type Activity Number = Numeric
Cell Style Status Finished = background-color:green
Cell Style Status Not started = background-color:red
Cell Style Status Ongoing = background-color:yellow
List Menu Commands = New, Last day, Help
Menu commands = List, New, Edit, Delete, Help
List Display = Activity number, Main Activity task, Activity Task, Start time, Resources, Task Type, Status
Page Title = Deployment plan PRIMA SSG - $Subject
List after submit = 1
Reverse sort = 1
Quick filter = Main Activity task, Resources, Task Type, Status
|
Ok, here it is. You wrote
Format Activity number = ,,,3,3
who told you that you can just leave out the first three arguments? The documentation says that you can trailing parameters can be omitted, not leading. So what you want is
Format Activity number = 0,attribname,attribvalue,3,3
/Stefan
|
Sorry!
I´m not so familiar with the meaning of trailing and leading in english.
But now it works!
Thank you very much!
|
Disable Preview button, posted by UlfO on Thu Sep 27 10:51:25 2012
|
Hi,
Is it possible to disable the Previewbutton?
Regards
Ulf Olsson
|
Re: Disable Preview button, posted by Stefan Ritt on Thu Sep 27 11:04:09 2012
|
UlfO wrote: |
Hi,
Is it possible to disable the Previewbutton?
Regards
Ulf Olsson
|
Nope. |
Re: Disable Preview button, posted by UlfO on Thu Sep 27 11:22:36 2012
|
Stefan Ritt wrote: |
UlfO wrote: |
Hi,
Is it possible to disable the Previewbutton?
Regards
Ulf Olsson
|
Nope.
|
Is it possible for you to implement this function in a future version of ELOG? |
Re: Disable Preview button, posted by Stefan Ritt on Thu Sep 27 11:26:36 2012
|
UlfO wrote: |
Stefan Ritt wrote: |
UlfO wrote: |
Hi,
Is it possible to disable the Previewbutton?
Regards
Ulf Olsson
|
Nope.
|
Is it possible for you to implement this function in a future version of ELOG?
|
If there is a good reason for that ... |
Re: Disable Preview button, posted by UlfO on Thu Sep 27 12:26:09 2012
|
Stefan Ritt wrote: |
UlfO wrote: |
Stefan Ritt wrote: |
UlfO wrote: |
Hi,
Is it possible to disable the Previewbutton?
Regards
Ulf Olsson
|
Nope.
|
Is it possible for you to implement this function in a future version of ELOG?
|
If there is a good reason for that ...
|
The reason for doing this is that the GUI will be cleaner and easier for the users to understand.
If it´s possible to disable functions that you don´t need in a customized ELOG it would be easier to explain how to work with it.
|
Mysterious Emboldened lines in threaded (collapsed) mode, posted by David Pilgram on Mon Sep 17 13:42:50 2012
|
I upgraded my system, including the version of Firefox.
I normally view the topic in Threaded Collapsed mode, right click on the entry I want to reply to, to open a new
Tab. However, I made a mistake an opened a new Window, as the two 'open' modes in Firefox swapped around.
But no worry, I thought, made my reply as usual.
However, when refreshing the topic afterwards, seemingly randomly distributed throughout the topic were
additional lines, with the latest entry showing up emboldened (but not as a clickable link), and the only
difference being the ID number which showed as 0 (zero).
Deleting the reply only caused the previous reply to show up randomly etc.
In effect, the latest entry is (randomly?) scattered throughout the topic - even in between entries older than
any in that thread, so it's not individial entries in that thread showing up.
The only way to get rid of it was to erase the whole directory, and re-install from backup (which, as it was the
first entry since the new installation, wasn't painful). It's been fine since - but only so long as I open a
thread in a new tab, and not in a new Window.
I guess the real question is just what is added to some file - perhaps the .cfg file? - that using a separate
window causes this behavioir? Any whay only as a new window, and given how elog is supposed to work on many
computers, why on this stand-alone computer running two sets of the same browser?
It happened once before at the end of last year during a regression backwards owing to the newer computer
failing and turning back to an older one with older OS and older firefox, where I did the same thing (in
reverse). As I didn't investigate at that time, I still have the mystery line showing up in that topic.
Sorry this is a bit rambling, but its very hard to describe! |
Re: Mysterious Emboldened lines in threaded (collapsed) mode, posted by Andreas Luedeke on Tue Sep 18 10:05:27 2012
|
> I upgraded my system, including the version of Firefox.
> [...]
> Sorry this is a bit rambling, but its very hard to describe!
A picture can say more than thousand words.
Can you reproduce this with a simple configuration?
If yes, can you attach the configuration, the *a.log files,
a description of what firefox version you're using and please:
some screenshots of "before" and "after"?
Thanks!
Andreas |
Re: Mysterious Emboldened lines in threaded (collapsed) mode, posted by David Pilgram on Tue Sep 18 18:41:05 2012
|
> > I upgraded my system, including the version of Firefox.
> > [...]
> > Sorry this is a bit rambling, but its very hard to describe!
>
> A picture can say more than thousand words.
> Can you reproduce this with a simple configuration?
> If yes, can you attach the configuration, the *a.log files,
> a description of what firefox version you're using and please:
> some screenshots of "before" and "after"?
>
> Thanks!
> Andreas
That's odd, I cannot reproduce the problem today - except on the topic [logbook] it already exists on.
Yet nothing has changed.
I've looked for hidden files, hidden control codes in the *a.log files... this one had better be put on the
back burner until I can find a way to reproduce it (!). |
HTML editor, posted by Josef Uher on Sun Sep 16 18:40:06 2012
|
Hi All,
maybe I missed something in the configuration, but how do I get this nice editor for HTML like the one available on this forum?
Thanks a lot for advice. |
Re: HTML editor, posted by Andreas Luedeke on Mon Sep 17 09:16:38 2012
|
Josef Uher wrote: |
[...] maybe I missed something in the configuration, but how do I get this nice editor for HTML like the one available on this forum?[...]
|
The fckeditor is already installed with the elog package. All you need to do is to enable HTML in ELOG and Javascript in your browser.
The ELOG command "Allowed encoding = 7" gives you the same encoding choices as in this forum. |
Re: HTML editor, posted by Josef Uher on Mon Sep 17 15:14:46 2012
|
Andreas Luedeke wrote: |
Josef Uher wrote: |
[...] maybe I missed something in the configuration, but how do I get this nice editor for HTML like the one available on this forum?[...]
|
The fckeditor is already installed with the elog package. All you need to do is to enable HTML in ELOG and Javascript in your browser.
The ELOG command "Allowed encoding = 7" gives you the same encoding choices as in this forum.
|
Hi Andreas, thank you for your reply. I have already found out that the problem on Mac was that I moved the cfg file to some other folder which did not contain the resources and scripts. I used the "-s" switch and now it works nicely. However, now I try to do the same thing on Windows and even the "-s" switch does not help (the default encodings etc. are set in the cfg file). I compiled the elog on Mac, but I used the installation package on Windows. |
Crash with long image names, posted by Josef Uher on Sun Sep 16 21:14:12 2012
|
Hi All,
I found that elog crashes if I try to upload an image with long name. It actually uploads the file after the crash. It crashes also if in the full view with attachments visible. If I shorten the name all is fine.
The crash report screenshot is attached. It looks like a too small buffer (?).

|
ELOG crashes when editing threads, posted by Louis de Leseleuc on Fri Sep 14 17:59:44 2012
|
Hi,
I am experiencing repeated crashing of the elog daemon.
If I go into select mode while in threaded view, I can select an entire thread by selecting the top entry.
When I do so then press the Edit button, the server crashes.
I have to manually restart it. Syslog shows no error.
This does not happen under Summary or Full view.
Running Ubuntu 12.04, ELOG 2.9.2-2455
I can provide my elog.cfg if necessary.
Cheers!
Louis
P.S. i just crashed the forums ELOG following those same steps!! Sorry!! At least it was restarted in no time. |
Type <attribute> = Date - Issue, posted by Garret Delaronde on Fri Sep 7 18:19:38 2012
|
I haven't found anything in the forums about this. Apologies if its a duplicate.
I am fairly familiar with ELog, use it for multiple purposes on 5 different Virtual Servers at work.
Currently looking to do some updates to one of the instances with the Date Type setting.
We have 17,000 entries all which have had manual entries for a Date Attribute for the last year and 8 months.
Due to regular entry errors on part of our contractors using it, (Eg: using "Aug" instead of "08", or using "-" instead of "/"), I want to change over to using the date type attribute (Type <attribute> = Date).
However the problem i found, the moment i save this in the config, and go to the list of entries, the date has changed on all of the entries to 12/31/1969. Which is BAD for our operation. So after removing the Type Date Setting the dates go back to normal.
Is there anyway to retain those dates so they display as they are and then only new entries would fall under the new date type setting?
Syntax manual didn't help much for this issue. |
Re: Type <attribute> = Date - Issue, posted by David Pilgram on Fri Sep 7 19:08:27 2012
|
Garret Delaronde wrote: |
I haven't found anything in the forums about this. Apologies if its a duplicate.
I am fairly familiar with ELog, use it for multiple purposes on 5 different Virtual Servers at work.
Currently looking to do some updates to one of the instances with the Date Type setting.
We have 17,000 entries all which have had manual entries for a Date Attribute for the last year and 8 months.
Due to regular entry errors on part of our contractors using it, (Eg: using "Aug" instead of "08", or using "-" instead of "/"), I want to change over to using the date type attribute (Type <attribute> = Date).
However the problem i found, the moment i save this in the config, and go to the list of entries, the date has changed on all of the entries to 12/31/1969. Which is BAD for our operation. So after removing the Type Date Setting the dates go back to normal.
Is there anyway to retain those dates so they display as they are and then only new entries would fall under the new date type setting?
Syntax manual didn't help much for this issue.
|
Hi Garret,
Why cannot you just use $entry time ? It uses the date that the entry was made which appears as the first line of every elog entry -
[Sorry for mis-post, just discovered cannot put the 'dollar at' control set in an entry]
MID: 12458
Date: Fri, 07 Sep 2012 17:22:06 +0100
In reply to: 12453
You can use 'Time format = ' to get the date to display in the format you like. You will see I have posted an issue about 'Date format = '. I mention this because in trying to understand what was happening, I too had a case where all the dates were showing as the same in a thread. I suspect your 12/31/1969 was due to the entries as being read were non-existant or blank.
Of course I may have mis-understood your requirements.
|
Re: Type <attribute> = Date - Issue, posted by Garret Delaronde on Mon Sep 10 17:18:03 2012
|
David Pilgram wrote: |
Garret Delaronde wrote: |
I haven't found anything in the forums about this. Apologies if its a duplicate.
I am fairly familiar with ELog, use it for multiple purposes on 5 different Virtual Servers at work.
Currently looking to do some updates to one of the instances with the Date Type setting.
We have 17,000 entries all which have had manual entries for a Date Attribute for the last year and 8 months.
Due to regular entry errors on part of our contractors using it, (Eg: using "Aug" instead of "08", or using "-" instead of "/"), I want to change over to using the date type attribute (Type <attribute> = Date).
However the problem i found, the moment i save this in the config, and go to the list of entries, the date has changed on all of the entries to 12/31/1969. Which is BAD for our operation. So after removing the Type Date Setting the dates go back to normal.
Is there anyway to retain those dates so they display as they are and then only new entries would fall under the new date type setting?
Syntax manual didn't help much for this issue.
|
Hi Garret,
Why cannot you just use $entry time ? It uses the date that the entry was made which appears as the first line of every elog entry -
[Sorry for mis-post, just discovered cannot put the 'dollar at' control set in an entry]
MID: 12458
Date: Fri, 07 Sep 2012 17:22:06 +0100
In reply to: 12453
You can use 'Time format = ' to get the date to display in the format you like. You will see I have posted an issue about 'Date format = '. I mention this because in trying to understand what was happening, I too had a case where all the dates were showing as the same in a thread. I suspect your 12/31/1969 was due to the entries as being read were non-existant or blank.
Of course I may have mis-understood your requirements.
|
Tried using the Time format setting, however I only want the time to be selected, so when i enter the datetime type it shows the date and time.
If there was a way to just have the time to be drop down menus vs the date and time all together, I would find that helpful.
As for the "$entry time" suggestion, it only serves to log the exact time the entry was made into elog. Where as I want it to be manually set.
In this example we've created an sql script to pull information from an oracle database, which then creates an elog entry.
We have multiple fields which are populated and locked so only admin can edit them.
Our contractor then edits the entry with a date / time / location, and a few other things.
the Date and Time are separate attributes. We'd prefer to keep it like that just because of the other scripts that run on the elog entries, (pulls day by day reports and formats and calculates summaries in excel automatically).
Any other suggestions would be helpful.
Thanks for your reply. |
Re: Type <attribute> = Date - Issue, posted by Andreas Luedeke on Wed Sep 12 10:50:40 2012
|
Garret Delaronde wrote: |
I haven't found anything in the forums about this. Apologies if its a duplicate.
I am fairly familiar with ELog, use it for multiple purposes on 5 different Virtual Servers at work.
Currently looking to do some updates to one of the instances with the Date Type setting.
We have 17,000 entries all which have had manual entries for a Date Attribute for the last year and 8 months.
Due to regular entry errors on part of our contractors using it, (Eg: using "Aug" instead of "08", or using "-" instead of "/"), I want to change over to using the date type attribute (Type <attribute> = Date).
However the problem i found, the moment i save this in the config, and go to the list of entries, the date has changed on all of the entries to 12/31/1969. Which is BAD for our operation. So after removing the Type Date Setting the dates go back to normal.
Is there anyway to retain those dates so they display as they are and then only new entries would fall under the new date type setting?
Syntax manual didn't help much for this issue.
|
The problem is, that the existing entries have a string content for this specific attribute.
An attribute with a "date" type content should contain a integer number, which represents the seconds of the epoch (starting with zero on 1-Jan-1970 at 00:00:00).
What you need to do is writing a script that reads all *a.log files in the logbook directory and converts lines of the type:
<attribute>: <text>
to lines like
<attribute>: $(date -d "<text>" +%s)
Unfortunately elog does not provide you with such a tool.
But since you have to write it now anyway now, you could submit your code to this forum 
Andreas |
secure way to allow users create logbook, posted by Szu-Ching Peckner on Tue Aug 28 23:02:07 2012
|
I don't think there is a good secure way so far, but would like to have your opinion.
If I want user to create logbook for themselves, what's the best way to do it? I guess Execute $attribute = <command> may work, have it write to cfg file, but obviously it impose security problem. Is there a good and secure way to allow user to create logbook themselves? |
Re: secure way to allow users create logbook, posted by Stefan Ritt on Wed Aug 29 10:46:49 2012
|
Szu-Ching Peckner wrote: |
I don't think there is a good secure way so far, but would like to have your opinion.
If I want user to create logbook for themselves, what's the best way to do it? I guess Execute $attribute = <command> may work, have it write to cfg file, but obviously it impose security problem. Is there a good and secure way to allow user to create logbook themselves?
|
Actually there is no good secure way. What I usually do is to give users admin rights on individual logbooks, then they can change the config of that logbook. Many times adding some attribute is as good as creating new logbooks. Like if you need two logbooks "home" and "work", you can create an attribute "type" and let the type be "home" or "work". With conditional attributes you can make the logbook behave differently for the two values of "type" and get most functionality of two separate logbooks.
- Stefan |
Re: secure way to allow users create logbook, posted by Szu-Ching Peckner on Wed Aug 29 14:35:45 2012
|
Stefan Ritt wrote: |
Szu-Ching Peckner wrote: |
I don't think there is a good secure way so far, but would like to have your opinion.
If I want user to create logbook for themselves, what's the best way to do it? I guess Execute $attribute = <command> may work, have it write to cfg file, but obviously it impose security problem. Is there a good and secure way to allow user to create logbook themselves?
|
Actually there is no good secure way. What I usually do is to give users admin rights on individual logbooks, then they can change the config of that logbook. Many times adding some attribute is as good as creating new logbooks. Like if you need two logbooks "home" and "work", you can create an attribute "type" and let the type be "home" or "work". With conditional attributes you can make the logbook behave differently for the two values of "type" and get most functionality of two separate logbooks.
- Stefan
|
Thanks, that is good option. |
Re: secure way to allow users create logbook, posted by Szu-Ching Peckner on Wed Aug 29 18:16:37 2012
|
Stefan Ritt wrote: |
Szu-Ching Peckner wrote: |
I don't think there is a good secure way so far, but would like to have your opinion.
If I want user to create logbook for themselves, what's the best way to do it? I guess Execute $attribute = <command> may work, have it write to cfg file, but obviously it impose security problem. Is there a good and secure way to allow user to create logbook themselves?
|
Actually there is no good secure way. What I usually do is to give users admin rights on individual logbooks, then they can change the config of that logbook. Many times adding some attribute is as good as creating new logbooks. Like if you need two logbooks "home" and "work", you can create an attribute "type" and let the type be "home" or "work". With conditional attributes you can make the logbook behave differently for the two values of "type" and get most functionality of two separate logbooks.
- Stefan
|
Is there a way to set user permission based on certain attribute? can Allow command = <user list> based on attribute?
for example, say type home, user1 can read, user2 can write, user3 can not access type home, but can access type work.
In short, is access control available when I use type to get functionality of separate logbooks? If so, how is this access control done?
|
Re: secure way to allow users create logbook, posted by Stefan Ritt on Thu Aug 30 10:00:07 2012
|
Szu-Ching Peckner wrote: |
Stefan Ritt wrote: |
Szu-Ching Peckner wrote: |
I don't think there is a good secure way so far, but would like to have your opinion.
If I want user to create logbook for themselves, what's the best way to do it? I guess Execute $attribute = <command> may work, have it write to cfg file, but obviously it impose security problem. Is there a good and secure way to allow user to create logbook themselves?
|
Actually there is no good secure way. What I usually do is to give users admin rights on individual logbooks, then they can change the config of that logbook. Many times adding some attribute is as good as creating new logbooks. Like if you need two logbooks "home" and "work", you can create an attribute "type" and let the type be "home" or "work". With conditional attributes you can make the logbook behave differently for the two values of "type" and get most functionality of two separate logbooks.
- Stefan
|
Is there a way to set user permission based on certain attribute? can Allow command = <user list> based on attribute?
for example, say type home, user1 can read, user2 can write, user3 can not access type home, but can access type work.
In short, is access control available when I use type to get functionality of separate logbooks? If so, how is this access control done?
|
Actually I never tried that. Using conditional attributes, you could try that out, but no guarantee that it works. Like
Options type = home{1}, work{2}
{1}Login user = you, me
{2}Login user = me, other
You could play with "login user", "Allow command" and "Deny command".
/Stefan |
Re: secure way to allow users create logbook, posted by Szu-Ching Peckner on Thu Aug 30 22:47:50 2012
|
Stefan Ritt wrote: |
Szu-Ching Peckner wrote: |
Stefan Ritt wrote: |
Szu-Ching Peckner wrote: |
I don't think there is a good secure way so far, but would like to have your opinion.
If I want user to create logbook for themselves, what's the best way to do it? I guess Execute $attribute = <command> may work, have it write to cfg file, but obviously it impose security problem. Is there a good and secure way to allow user to create logbook themselves?
|
Actually there is no good secure way. What I usually do is to give users admin rights on individual logbooks, then they can change the config of that logbook. Many times adding some attribute is as good as creating new logbooks. Like if you need two logbooks "home" and "work", you can create an attribute "type" and let the type be "home" or "work". With conditional attributes you can make the logbook behave differently for the two values of "type" and get most functionality of two separate logbooks.
- Stefan
|
Is there a way to set user permission based on certain attribute? can Allow command = <user list> based on attribute?
for example, say type home, user1 can read, user2 can write, user3 can not access type home, but can access type work.
In short, is access control available when I use type to get functionality of separate logbooks? If so, how is this access control done?
|
Actually I never tried that. Using conditional attributes, you could try that out, but no guarantee that it works. Like
Options type = home{1}, work{2}
{1}Login user = you, me
{2}Login user = me, other
You could play with "login user", "Allow command" and "Deny command".
/Stefan
|
Thanks for reply Stefan.
I tried it, didnt work. I think its expected it didn't work though, or maybe I didn't try it right.
==============
[logbook1]
Login user = user1
Options Type = Home{1}, Work{2}
{1} Login user = user2
This will make user2 unable to login logbook1 at all
============
[logbook1]
Login user = user1, user2
Options Type = Home{1}, Work{2}
{1} Login user = user1
{2} Login user = user2
user1 can login, can search Work type entries, create new entry with Work type.
==============
[logbook1]
Login user = user1, user2
Options Type = Home{1}, Work{2}
{1} Deny New = user1
user1 can still create entries for Home type. I think it's because when user1 login, command New is available for user1, so when user1 click on New, doesn't matter what type user1 choose, submit button is available. If I have Deny New = user1 under logbook1, New is not available, that means user1 can't create entry for Work type either.
===============
seems to me under current code, access control has to be done based on logbook, not attribute. Do you agree?
if that's the case, we may have a lot of logbook because of access control we want to implement. So there is another question:
selection page show all logbooks. Is there a way to make selection page and tabs show logbooks based on user access?
For example, we have 20 logbooks, user1 has acces to 3, when user1 login, selection page only shows that 3 logbooks for user1, and only 3 tabs for user1.
I thought about using group to get logbooks more organized, however I will still face the situation that one group may have 20 logbooks.
Or what would you do to handle this situation? (I asked selection page question earlier in another entry). Maybe we should discuss on that entry? Message ID: 67319
Thanks again.
|
|